Catch security choices at the architecture stage — where they're still cheap.
Architecture and threat-model review for new and migrating systems. Threat-model-driven design with explicit attacker capability assumptions, cryptography review, identity-and-authorisation architecture. Manual, expert-led — no auto-generated threat diagrams, no LLM-driven model output.
Before the system is built — not after it ships.
Pentesting a deployed system is finding bugs in choices that have already been made. Architecture review is a different shape of work: we are looking at the choices before they have been made, when changing them is still a meeting rather than a six-month migration.
We are most useful for new systems being designed, systems migrating to new platforms or jurisdictions, systems where the threat model is shifting (new adversary profile, new regulatory boundary, new sovereign requirement), and refactor projects where security is one of the drivers.
We are less useful for "review the architecture document we wrote last year" — that is closer to a pentest of the deployed system.
The shape of the review.
STRIDE, LINDDUN, PASTA — used as the framework for facilitated workshops with the customer's engineering team. Output is a written threat model, not a Visio diagram.
Trust boundaries, data flows, deployment topology, failure modes. We read the customer's architecture documents and ask the questions an attacker would ask.
Protocol selection, primitive choice, key-management architecture, post-quantum readiness. Implementation review where the customer is shipping their own crypto.
Authentication design, federation, session management, authorisation models (RBAC, ABAC, ReBAC), token-handling architecture.
Architectures with hard data-residency or air-gap requirements. Update channels, telemetry, key-distribution, and offline-operation primitives.
Fail-secure vs fail-open analysis, blast-radius modelling, dependency-graph review, incident-response readiness in the architecture.
The shape we don't ship.
- No auto-generated threat diagrams
Tools that ingest a system description and output a "threat model" produce decorative artefacts that get filed and forgotten. The work that matters is the conversation, the dissent, and the written reasoning.
- No "review-the-deployed-system" reviews
When the architecture is already deployed and the customer cannot change it, what they need is a pentest, not an architecture review. We will say so and route the work accordingly.
- Local LLMs as tooling, not as methodology
We do not let an LLM generate the threat model. We do use local LLMs in-house to summarise long architecture documents, scaffold meeting notes, and pattern-match against our threat library. Customer architecture material never goes to a commercial SaaS model.
Three forms of engagement.
Pre-build review. The customer is designing a new system. We sit alongside the architecture team during design and produce a written threat model and architecture review.
Mid-build advisory. The system is partly built. We review what exists, identify the load-bearing security choices that still need to be made, and stay engaged as those choices are landed.
Refactor advisory. An existing system needs an architecture-level rework. We model the target architecture, identify migration risks, and advise on the path between today's system and the target.
Duration depends on the scope and complexity. We scope against the actual system.