Threat-model trust boundaries before a penetration test by turning the architecture into falsifiable security hypotheses. The scope should describe identities, trust zones, data flows, privileged transitions and abuse cases, then connect each one to an observable test objective. This prevents the assessment from becoming a list of endpoints and forces it to challenge the design assumptions that could create systemic compromise.
Why an endpoint inventory is not a threat model
An endpoint list says where requests arrive. It rarely explains which component authenticates the caller, which downstream service trusts the result, where tenant context is added, or which privileged action becomes possible after a transition. Two endpoints with identical technology can carry radically different risk because one crosses an administrative, tenant, network or data-classification boundary.
The architect’s job is not to predict every vulnerability. It is to expose assumptions that the test can try to disprove: an internal route cannot be reached externally, a service token cannot cross domains, a user-controlled identifier is rebound to the authenticated tenant, or a background worker revalidates authorization before acting.
Establish the architecture evidence pack
- Current context and container diagrams, not a historical presentation.
- Identity providers, token issuers, session stores and machine-identity mechanisms.
- Ingress, gateway, service mesh, load balancer and direct-service routes.
- Data stores, object storage, caches, queues, exports and analytics paths.
- Administrative planes, support tooling, deployment systems and break-glass paths.
- Third-party callbacks, webhooks, federations and customer-controlled integrations.
Mark uncertainty explicitly. An unknown route, owner or credential flow is a discovery target, not a reason to omit the component. Record diagram date, environment and source so testers can distinguish confirmed design from inference.
Map identities before assets
List human, machine and workload identities: anonymous visitor, customer user, tenant administrator, support operator, CI job, scheduled worker, gateway, microservice and third-party integration. For each identity, record credential type, issuer, audience, lifetime, revocation path and where authorization is ultimately enforced.
Include identity transformations. A user session may become a gateway assertion, a service token and then a queue message. Every transformation can lose actor, tenant, purpose or scope. The test should verify that the final consumer cannot be tricked into granting more authority than the original caller possessed.
Draw trust zones that reflect control, not topology
A subnet boundary is not automatically a trust boundary, and a shared cluster is not automatically one trust zone. Separate areas when administrators, credentials, policy engines, data classification or blast radius differ. Typical zones include public edge, customer workload, shared application services, control plane, security tooling, data plane and third-party systems.
- Who can originate traffic in the zone?
- Which identity proof is accepted at entry?
- Which policy decision is assumed to have happened upstream?
- Which assets become reachable after entry?
- What telemetry proves or disproves the transition?
Trace critical data flows end to end
Choose the flows whose compromise would matter: sign-in, password recovery, payment, privileged configuration, document sharing, export, secret retrieval and tenant provisioning. Trace request data, credentials and authorization context through synchronous services, queues, caches, storage and outbound integrations until the authoritative side effect is complete.
Label encryption changes, parsing steps, deserialization, identifier translation, cache keys and persistence. A flow is incomplete if it stops at the API response while a worker later performs the sensitive action.
Identify privileged transitions
Prioritize transitions where ordinary input gains administrative effect: user to tenant admin, tenant admin to platform support, application service to cloud control plane, webhook to provisioning, CI identity to production deployment, or file upload to server-side processing. State the intended preconditions and prohibited alternatives for each transition.
Convert assumptions into abuse cases
- Write the protected invariant in plain language.
- Name an actor with less privilege than the invariant requires.
- Describe the boundary or transformation the actor would need to subvert.
- Define the smallest safe action that would prove the failure.
- Specify evidence, cleanup and a stop condition before testing.
For example: “A tenant administrator cannot cause a worker to export another tenant’s records by changing an object identifier after the gateway authorizes the request.” This is more testable than “test IDOR” because it identifies identity, asynchronous transition, asset and prohibited outcome.
Build a trust-boundary test matrix
For every material boundary, vary actor, credential state, tenant, route, protocol and object ownership. Include expired and revoked credentials, direct downstream access, alternate hosts, duplicate delivery, cached authorization and administrative APIs. Mark each hypothesis as tested, blocked, not applicable or residual risk; do not silently treat lack of access as a pass.
Evidence expected from the assessment
- Exact request or action and the identity used.
- Observed decision at each relevant control point.
- Authoritative data or state before and after the test.
- Logs or correlation identifiers spanning the transition.
- Architecture assumption confirmed or disproved.
- Blast radius and repeatability without speculative escalation.
Set safety boundaries around high-impact hypotheses
Agree test tenants, synthetic data, rate limits, excluded control-plane actions and emergency contacts. Use canary objects for destructive transitions. If the hypothesis involves production identities or cloud privileges, prove the minimum effect and stop before persistence, broad enumeration or unrelated customer impact.
Use findings to update architecture
A finding should name the failed boundary and control ownership, not only the vulnerable URL. Remediation may belong in identity propagation, gateway policy, service authorization, queue schema, platform guardrails or data partitioning. Update diagrams and threat assumptions after the fix so the architecture record does not preserve the condition that produced the defect.
Retest the design, not only the original payload
Repeat the original proof, then approach the same boundary through alternate routes, identities and consumers. A local input check can block one request while the architectural assumption remains false elsewhere. Successful retesting demonstrates the invariant across the intended enforcement layer.
Use the NIST Technical Guide to Information Security Testing and Assessment to structure planning and evidence, and the OWASP Web Security Testing Guide for application techniques. The threat model supplies the system-specific hypotheses those references cannot infer.
The architecture decision
A useful pre-test threat model is small enough to drive execution and precise enough to expose design assumptions. Map identities, trust zones, critical flows and privileged transitions; turn them into abuse cases with observable outcomes; and require the report to connect evidence back to the failed or validated architecture invariant.
Ask WIMD to design an architecture-led penetration test that challenges the trust boundaries with the greatest business blast radius.