Guide
Security Readiness Guide
Building a Zero Trust architecture for modern digital platforms and APIs.
Zero Trust is often sold as a product. It is an architectural position: no request is trusted because of where it came from. Here is what that actually requires in a platform built on APIs.
Identity is the new perimeter
In a network-perimeter model, being inside the network implied authorisation. That assumption fails the moment you have remote staff, third-party integrations, or more than one cloud environment — which is to say, immediately.
Every request should carry a verifiable identity, whether it originates from a person, a service, or a scheduled job. Service-to-service calls that authenticate with a shared static secret are the most common gap we find in otherwise well-built platforms.
Authorise per request, at the resource
Checking permissions at the API gateway is necessary but not sufficient. Authorisation decisions belong close to the data, where the full context of the request is available — who is asking, for which record, under what conditions.
Coarse role checks tend to drift into over-permissioning as an organisation grows. Attribute-based rules evaluated per request age better, because they encode the actual policy rather than a snapshot of the org chart.
Assume credentials will leak
Design so that a leaked credential has limited blast radius and a short useful life. Short-lived tokens, scoped narrowly to a single purpose, are worth considerably more than a longer password policy.
- Issue short-lived, narrowly scoped tokens rather than long-lived API keys
- Rotate automatically; if rotation requires a human, it will not happen
- Never let secrets reach source control — enforce this with automated scanning
- Separate credentials per environment so a staging leak cannot touch production
Log what an investigator would need
The value of an audit log is decided during an incident, when it is far too late to add fields to it. Log the identity, the resource, the action, the outcome, and the source — for successes as well as failures.
Store logs somewhere the application itself cannot modify. An attacker with application access should not be able to erase the record of what they did.
Rehearse the response
An incident response plan that has never been executed is a document, not a capability. Run the exercise: revoke a credential, isolate a service, restore from backup. Time each step and fix whatever turned out to be slower or more manual than expected.
Working through this in your own organisation?
Tell us where you are stuck and we'll respond with a practical next step — no pitch decks.
Start a conversation