Security on architecture level
The term Security Architecture has many meanings depending on the context: In this service’s context it defines the hardening of your architecture by including security controls and multiple layers of defense (Defense-in-Depth) right from the beginning. This does not only take the implementation layer of your applications into account, but also focuses more on architecture and component level.
If you answer any of these questions with yes, then security architecture consulting might be a good idea to include in your process at an early stage:
- You want to change your architecture towards a microservice design?
- You want to shift parts of your architecture into the cloud?
- You want to offer previously customer-hosted services also as SaaS solutions?
- You want to move towards a more container-based component approach?
- You want to connect multiple clients (including mobile apps) and systems to your APIs?
- You’re integrating GenAI components (LLMs, RAG pipelines, MCP tools, or agentic AI) and want to review attack surfaces like prompt injection, tool poisoning, or data exfiltration vectors?
- You want to evaluate your architecture against zero trust principles — verifying that lateral movement, privilege escalation, and trust boundary weaknesses are addressed?
- Or simply: You just want to discuss your architecture (existing or planned) with a security expert?
In all these cases security architecture consulting is the process of discussing your software and system design with a security expert with a strong background in software architecture.
Individual consulting package
For supporting you in these scenarios with my architecture and security experience in the best possible way, a short conf-call to discuss your individual requirements makes sense. After that I can offer you an individual security architecture consulting package, targeted at your specific situation: Let’s talk
Zero trust architecture review
A specific variant of security architecture consulting that I’m seeing increasing demand for is assessing architectures against zero trust principles. The core question is: if an attacker gets past your perimeter — and sooner or later they will — what actually stops them?
Coming from an offensive security background, I approach zero trust differently than network or infrastructure consultants. Instead of starting with vendor product catalogs, I start with attack paths: What can a compromised service account access? How far can an attacker move laterally from a single compromised container? What happens when a developer’s credentials are phished? The answers to these questions reveal where zero trust principles need to be applied — and where they’re already missing.
A zero trust architecture review typically covers:
- Identity verification: How authentication and authorization are enforced across services, users, and machine identities — not just at the perimeter
- Least privilege: Whether service accounts, IAM roles, and RBAC policies actually follow least privilege in practice, or whether broad permissions have accumulated over time
- Microsegmentation: Network policies, security groups, pod isolation, and service mesh configurations that limit blast radius when a component is compromised
- Continuous verification: Whether trust is re-validated at each step or implicitly inherited from initial authentication
- Data protection: Encryption in transit between internal services, key management, and secrets handling
The output is a concrete assessment of where your architecture deviates from zero trust principles, prioritized by exploitability — because not every gap is equally dangerous. Where relevant, I combine this with threat modeling using Attack Tree to map the actual attack paths that the zero trust gaps enable.
Relation to threat modeling
Depending on your concrete needs, a security architecture review can include or can be executed as a threat modeling workshop, which details the risks of the architecture under review: See Agile Threat Modeling
This service also supports technical security requirements commonly referenced in modern cybersecurity regulations.