Trust Boundary Violations
Trust boundaries define where one security context ends and another begins: internal network versus public internet, one microservice versus another, one tenant's data versus another's. The most common design flaw we find is implicit trust across these boundaries, where an internal API accepts requests from a public-facing gateway without re-validating identity or authorization, or where inter-service calls carry no authentication at all because "it's all internal." These gaps become the primary path for lateral movement once any single component is compromised.
Common pattern
An API gateway authenticates external requests but internal services behind it communicate over plain HTTP with no service-to-service authentication, treating network-level isolation as a substitute for identity verification.
Authentication & Identity Design Flaws
Authentication design flaws go beyond weak passwords. We look at the structural decisions: how tokens are issued, scoped and rotated; whether session binding prevents token replay across devices; how federated identity trust is established and validated; and whether step-up authentication is required for sensitive operations. A common finding is that the primary login flow is well-designed but secondary flows (API key generation, service account provisioning, machine-to-machine tokens) bypass the same controls entirely.
Common pattern
User-facing authentication uses short-lived JWTs with proper rotation, but service accounts use long-lived API keys with no expiry, no rotation schedule and overly broad scopes that persist even after the responsible team changes.
Data Protection & Encryption Gaps
Encryption is rarely all-or-nothing. Most systems encrypt data in transit (TLS) and often at rest at the storage level, but gaps appear in the middle: temporary files written in plaintext during processing, PII cached in unencrypted Redis instances, sensitive fields logged before masking is applied, or backups stored without the same encryption as the primary data store. We map the full data lifecycle and identify every point where sensitive data exists outside encryption coverage.
Common pattern
The primary database uses transparent data encryption, but an analytics pipeline extracts PII into a data warehouse where encryption at rest is not enabled, and ETL staging tables hold plaintext copies of sensitive fields.
Insufficient Logging & Audit Design
Security monitoring only works when every security-relevant event is captured with sufficient detail to reconstruct what happened. Architectures frequently log application errors but miss security events: failed authentication attempts, authorization denials, privilege changes, data exports, administrative actions, and configuration changes. Without these, incident response teams have no forensic trail and compliance auditors have no evidence of control effectiveness. We assess what is logged, where it is stored, whether it is tamper-proof, and whether retention meets regulatory requirements.
Common pattern
Application logs capture HTTP errors and performance metrics but do not record authorization decisions, and audit logs for administrative actions exist only in the identity provider with no forwarding to the SIEM.
Inter-Service Communication Risks
In distributed architectures, the security of inter-service communication determines whether a single compromised service leads to a full breach. We evaluate whether east-west traffic uses mutual TLS, whether service identities are properly scoped, whether message queues enforce producer/consumer authorization, and whether circuit breakers and rate limiters protect against denial-of-service propagation. A recurring finding is that services trust message content from other internal services without validation, allowing a compromised upstream service to inject malicious payloads.
Common pattern
Microservices communicate over an internal network with no mutual TLS and no per-service authorization policy, relying entirely on network segmentation that does not exist in the Kubernetes cluster's flat network.
Third-Party Integration Exposure
Every external integration introduces a trust dependency. We review how third-party API credentials are stored and rotated, whether OAuth scopes are minimized, how webhook endpoints validate sender identity, and what happens to your system's availability and data integrity if a third-party service is compromised or goes offline. The blast radius of a third-party breach depends entirely on the architectural choices made at integration time: shared credentials, over-broad permissions, and missing input validation on incoming webhook data are the most common findings.
Common pattern
A single API key with full read/write access is shared across multiple third-party integrations, stored in environment variables with no rotation policy, and the same key is used in both production and staging environments.
Frequently Asked Questions About Security Architecture Review
What is a security architecture review?
A security architecture review is a design-level assessment of your system's structure, data flows, trust boundaries and security controls. Unlike penetration testing, which targets running code, an architecture review examines how components interact, where trust is assumed, and whether the controls in place match the threats the system actually faces. The output is a prioritized set of structural risks and actionable recommendations to address them before they become exploitable vulnerabilities.
How does a security architecture review differ from a penetration test?
A penetration test targets a running application to find exploitable vulnerabilities in code and configuration. A security architecture review operates earlier in the lifecycle: it examines the design itself, including data flow diagrams, trust boundaries, authentication and authorization models, encryption schemes and inter-service communication patterns. The goal is to identify structural weaknesses that would be expensive or disruptive to fix after deployment. Ideally both are performed: architecture review during design, penetration testing after deployment.
When should we schedule a security architecture review?
The highest-value timing is during the design phase of a new system or ahead of a significant architectural change such as migrating to microservices, adopting a new identity provider, adding multi-tenancy, or moving workloads to a new cloud region. Reviews are also valuable before compliance audits (ISO 27001, SOC 2) as they surface control gaps that auditors would flag. Some teams schedule reviews annually as part of their security program.
What documentation do we need to provide?
At minimum we need architecture diagrams (even informal ones), a description of major components and their responsibilities, data flow documentation showing how sensitive data moves through the system, and details of your authentication and authorization model. If available, infrastructure-as-code templates, API specifications, network topology diagrams and existing threat models accelerate the review. We can work with incomplete documentation and will flag gaps as findings.
How long does a security architecture review take?
A focused review of a single service or bounded context typically takes one to two weeks. A full enterprise architecture review covering multiple systems, identity infrastructure and data pipelines runs two to four weeks depending on complexity and documentation readiness. We agree on scope and timeline during an initial scoping call so there are no surprises.