Every security architecture makes the same implicit promise: when a component is compromised, the boundary contains the damage. The web interface falls, but the firmware holds. The mobile app is reverse-engineered, but the backend verifies. This promise is easy to draw and hard to keep, because it depends on every crossing point enforcing what the diagram assumes.
In practice, boundaries erode during development. A debug path is added that crosses without authentication. A service is split for performance, and the internal interface inherits trust that was never re-examined. A firmware update introduces a new component on the wrong side of a boundary. None of these changes look like security decisions, they look like engineering, and the diagram silently stops describing the product.
The architecture question is therefore not "do we have boundaries" but "does the implemented product still enforce the boundary the design promises". That question can only be answered by walking attack paths through the real system, not by reviewing the diagram.
Boundary integrity depends on several technical assumptions.
- Boundary definition Which trust boundaries actually exist in the implemented product, not just the design document?
- Crossing enforcement Is every crossing point authenticated and authorized, or do some transitions trust the caller by position?
- Privilege separation When a component on the low side is compromised, what privilege does the attacker inherit at the next boundary?
- Secret placement Which secrets are accessible from which side, and does a low-side compromise expose high-side credentials?
- Assumption validity Which assumptions (physical access is hard, internal networks are safe, debug is disabled) still hold in deployed products?
- Attack-path coverage Have the documented attack paths been walked end-to-end on the real product?
- Drift since design Which implementation changes have moved components or added crossings since the architecture was last reviewed?
The boundary was drawn correctly. The implementation crossed it.
The architecture separates the user-facing interface from the control component with an authenticated boundary. During development, a diagnostic feature was added that calls across the boundary from a lower-privilege context, implemented for speed, authenticated by network position rather than identity.
The attacker compromises the interface component, uses the diagnostic path, and arrives inside the boundary with the privileges of a trusted internal caller. The drawing was never wrong; the product drifted away from it.
Validate the architecture by walking real attack paths.
We map the implemented trust boundaries from the running product, identify the crossings and the assumptions they carry, then walk the attack paths the architecture claims to block: compromising a low-side component and testing exactly what the boundary stops, and what it does not.
- New product architecture or major redesign
- Component split, merge or relocation
- A compromise raises the question of containment
- Architecture documentation and implementation have drifted apart
- Preparing or refreshing a threat model
- Customer assurance requires architecture validation