Zero trust as an architecture, not a product
Zero trust is frequently sold as something you buy. It is better understood as a design rule: no request is trusted because of where it came from. Every call authenticates, every call authorises, and network position grants nothing.
Applied properly this removes the single most damaging assumption in enterprise systems — that being inside the perimeter means being legitimate.
The controls that consistently matter
Across the assessments we run, the same small set of issues accounts for most of the real risk:
- Authorisation checked at the object level, not just the route
- Secrets held in a managed store and rotated, never in source or images
- Dependencies tracked with an SBOM and patched on a schedule
- Logging that captures security events without capturing credentials
- Backups that are restore-tested, not merely taken
- Least-privilege IAM reviewed on a cadence, not set once
Build the evidence as you go
Enterprise customers and auditors will eventually ask for proof: threat models, test results, access reviews, incident procedures. Producing that retroactively is expensive and unconvincing.
Generating it as a by-product of normal delivery — a threat model per significant feature, automated scanning in CI, quarterly access reviews with recorded outcomes — costs far less and stands up better under scrutiny.
Practise the incident before you have one
The response plan that has never been rehearsed will fail on the day. Run a tabletop exercise at least annually: pick a plausible scenario, walk the team through detection, containment, communication and recovery, and write down everything that was unclear.
The gaps that surface in a rehearsal are almost always cheaper to fix than the ones that surface at 3am.
Working on something like this?
We are happy to talk through the approach, whether or not it turns into a project.
Start a conversation
