A user connects through the corporate network.
A service runs in a private subnet.
A workload is deployed inside the production Kubernetes cluster.
A request originates from an internal IP address.
Traditional reasoning may treat those facts as evidence of trust:
inside network
therefore
trusted
The resulting architecture may allow:
- broad network reach
- long-lived sessions
- shared credentials
- inherited administrator access
- minimal verification between internal services
- permanent trust after one successful login
The boundary has done most of the security thinking.
Once a user or workload crosses it, the system becomes unusually generous.
Zero trust challenges that model.
It asks the system to evaluate identity, authority and context instead of assuming that location has already answered those questions.
WHO IS ACTING?
PROVED BY WHICH EVIDENCE?
MAY DO WHAT?
TO WHICH RESOURCE?
UNDER WHICH CONDITIONS?
FOR HOW LONG?
This sounds simple.
The phrase has still accumulated considerable marketing vapour.
A gateway, identity provider, service mesh or device-management platform may be presented as the missing zero-trust ingredient.
These technologies can support the model.
None becomes zero trust by itself.
Zero trust is an architectural approach that replaces broad, inherited trust with explicit identity, bounded authority, protected communication, enforceable policy and continuing evidence.
It does not remove trust from the system.
Distributed systems still trust:
- identity providers
- certificate authorities
- policy engines
- cryptographic keys
- operating systems
- cloud control planes
- software supply chains
- human administrators
The stronger question is:
Where does trust exist, how was it established, how far does it reach and how quickly can it be withdrawn?
Zero trust is bounded trust
The word trust is often used for several different things.
A clearer model separates them.
TRUST DEPENDENCY
A component whose claims
or behaviour the system relies on.
IDENTITY ASSURANCE
The strength and freshness
of evidence supporting an identity.
AUTHORITY
The action that identity
is permitted to perform.
For example:
Identity provider:
trusted to issue workforce claims
Authentication:
recent MFA on managed device
Authority:
read-only production investigation
Duration:
30 minutes
The identity provider is a trust dependency.
The authentication method creates a level of assurance.
The policy grants bounded authority.
These are related.
They are not interchangeable.
Authentication does not turn identity evidence into certainty.
A valid certificate, token or login supports a claim according to the strength of its issuer, key protection, verification method and freshness.
Authorisation then decides whether that claim is sufficient for one action.
Zero trust does not turn identity evidence into certainty, or identity into authority. It evaluates evidence, grants bounded authority and keeps the dependencies behind that decision visible.
Use an access-decision contract
A reusable access-decision contract makes the architecture easier to reason about.
ACCESS DECISION
Subject:
order-service
Identity issuer:
bfstore workload identity
Action:
call payment Authorise RPC
Resource:
payment-service/Authorise
Context:
production
approved workload
current credential
Authority:
one RPC class
Duration:
credential and policy lifetime
Enforcement:
payment service gateway
Evidence:
identity, decision and result recorded
Revocation:
credential expiry,
policy change or workload removal
The contract asks:
Who is acting?
Which evidence supports the identity?
Which action and resource are involved?
Which conditions affect the decision?
What is the smallest useful authority?
Where is the decision enforced?
How is access recorded?
How quickly can it be withdrawn?
The decision does not always need to be recomputed centrally for every packet.
It may be evaluated per request, when a credential is issued, when a session is renewed or when a sensitive action is attempted.
Its scope, freshness, cache lifetime and re-evaluation conditions should still be explicit.
Networks limit reach; they do not grant authority
A request from an internal IP address tells us something about its route.
It does not prove:
- which person initiated it
- which workload sent it
- whether credentials were stolen
- whether the caller may access the target
- whether the request is valid
NETWORK LOCATION
where the request came from
IDENTITY
who or what made the request
AUTHORITY
what the caller may do
These are different questions.
The opposite claim is equally weak:
Identity is enough.
The network no longer matters.
Identity limits authority.
Network policy limits reach.
IDENTITY POLICY
payment service may read
its payment credentials
NETWORK POLICY
payment service may communicate
with the approved secret endpoint
If identity policy is wrong, segmentation may still prevent unrelated reach.
If network policy is broad, resource authorisation can still deny the action.
They become layers rather than verdicts.
A VPN is therefore an access path, not a complete trust model.
Private networks, firewalls and segmentation remain valuable blast-radius controls.
Zero trust does not require every service to be exposed publicly so identity can prove its bravery.
Give subjects and resources explicit identities
Human users are only one identity population.
A cloud platform also contains:
- workloads
- CI jobs
- controllers
- infrastructure runners
- backup processes
- observability agents
Each needs an identity appropriate to its role.
HUMAN IDENTITY
Mariam
PlatformOperator
WORKLOAD IDENTITY
catalog-service
production
AUTOMATION IDENTITY
production-infrastructure-runner
Shared credentials weaken attribution, revocation and containment.
Suppose every bfstore service uses:
bfstore-runtime-user
Audit logs cannot distinguish catalog from payment.
A compromised review service may inherit payment permissions.
Revoking the credential affects every workload.
Separate identities create smaller security blast radii.
Resources also need stable identity and ownership.
Useful attributes may include:
- service
- environment
- owner
- data classification
- criticality
- account
- region
RESOURCE IDENTITY
service:
payment
environment:
production
classification:
restricted
owner:
payment-team
Without reliable resource identity, policy falls back to broad patterns and fragile naming assumptions.
Keep authentication and authorisation separate
Authentication evaluates evidence supporting a claimed identity.
Authorisation decides whether that identity may perform an action on a resource.
AUTHENTICATED
│
▼
KNOWN CLAIM
│
╳
│
NOT YET AUTHORISED
A successfully authenticated user is not automatically a production administrator.
A valid workload identity is not automatically allowed to read every secret.
For example:
Identity:
ApplicationDeveloper
Environment:
development
Action:
deploy
Result:
allowed
The same identity may request:
Environment:
production
Action:
modify network policy
Result:
denied
The identity has not changed.
The requested authority has.
Make authority narrow, conditional and temporary
Least privilege should be expressed across several dimensions.
WHO
catalog-service
ACTION
read
RESOURCE
catalog database credential
ENVIRONMENT
production
DURATION
temporary session
This changes the blast radius of compromise.
A catalog exploit grants catalog authority rather than the combined authority of the estate.
Short-lived credentials narrow the time dimension.
They do not guarantee immediate revocation.
A bearer token may remain valid until expiry unless enforcement can terminate the session, check revocation state or reject the credential early.
Short lifetimes bound revocation delay. They do not guarantee immediate revocation.
The architecture should understand:
- credential lifetime
- policy-cache duration
- certificate rotation
- group-membership propagation
- controller reconciliation delay
- session termination
Revocation time is part of the security model.
Treat context as evidence with provenance
A policy decision may consider:
- role
- device state
- environment
- workload identity
- image provenance
- resource classification
- session age
Those attributes are claims too.
For each one, the system should know:
VALUE
production workload
SOURCE
cluster identity service
FRESHNESS
issued two minutes ago
OWNER
platform identity team
MUTABILITY
workload cannot alter it
A policy is only as reliable as the provenance and freshness of the attributes it consumes.
If a workload can change its own environment label from development to production, the policy boundary is decorative.
Attribute-based access can reduce duplicated policy, but it can also introduce hidden coupling, difficult debugging and unexpected matches.
Reusable policies should be tested against representative subjects, resources and negative cases.
Trust delegation should be explicit
Trust should not spread silently through the dependency graph.
A trusts B
does not automatically mean
A trusts everything B trusts
Delegation is still possible.
The order service may accept a payment outcome asserted by the payment service.
The contract should define:
- which issuer may make the claim
- which claim type is accepted
- which audience may consume it
- how fresh it must be
- which validation rules apply
Trust should not propagate implicitly. Delegated claims should be accepted only under an explicit contract describing who may assert what, to whom and under which conditions.
The same principle applies to software supply chains.
Trusting a registry does not make every image safe.
Trusting a build system does not allow every workflow to deploy to production.
Protect the channel without confusing it with permission
Mutual TLS can help a client verify a server and a server identify a client.
That identity is only as strong as certificate issuance, private-key protection, rotation and enforcement.
A valid certificate proves possession of a key accepted by the issuer.
It does not prove that the process holding the key is uncompromised or acting correctly.
CERTIFICATE VALID
identity claim recognised
POLICY ALLOWED
requested action authorised
Encryption protects communication.
It does not validate intent.
An encrypted request can still be malicious, incorrect or excessive.
Infrastructure authorisation may decide:
may order-service call
payment-service/Authorise?
The payment application must still validate:
- order reference
- amount
- currency
- state transition
- duplication
- idempotency
A valid service identity should not be allowed to perform an invalid payment transition merely because its certificate is beautiful.
Operate decision and enforcement as one system
A policy decision point decides.
A policy enforcement point stops or permits the action.
REQUEST
│
▼
ENFORCEMENT POINT
│
▼
POLICY DECISION
│
├── allow
└── deny
Possible enforcement points include:
- cloud IAM
- API gateways
- service proxies
- secret managers
- databases
- admission controllers
- application code
A policy document or dashboard cannot contain an action by itself.
The decision and enforcement path should be tested together.
Decision evidence should include:
Decision:
denied
Policy:
payment-rpc-access-v7
Subject:
review-service
Resource:
payment-service/Authorise
Reason:
caller service is not permitted
Cache lifetime:
none
Correlation:
req-18472
Policy version, relevant attributes and decision reason make the system explainable.
The architecture should also define:
- allow and deny precedence
- local and central policy interaction
- exception handling
- stale cached decisions
- unavailable attribute sources
- conflicting metadata
Individually reasonable policies can produce an unusable combined system.
Evidence should support detection and response
Access logs should preserve enough information to answer:
Who acted?
Which authority allowed it?
Which resource was affected?
When did access end?
Evidence should be:
- attributable
- protected
- retained appropriately
- privacy-aware
- queryable
Recording an event is not the same as detecting misuse.
The operating model should also define:
- which events generate alerts
- which unusual patterns matter
- who owns investigation
- how quickly containment begins
Evidence supports accountability.
Detection and response turn it into active security control.
Protect control planes and automation
The cloud control plane remains one of the most powerful trust centres.
An administrator may lack network access to a database while retaining API authority to delete, snapshot or reconfigure it.
Leaving the control plane outside the zero-trust discussion would be rather like securing every window while lending out the demolition controls.
Automation identities deserve equally strict treatment.
A production Terraform runner or Crossplane provider may alter:
- networks
- clusters
- databases
- identities
- DNS
- storage
Automation is a high-speed user.
Its trust should be more explicit, not less.
Controls should include:
- separate identities by environment
- scoped account authority
- short-lived credentials
- reviewed source
- protected state
- known workflow and revision
- auditable execution
The platform should know which repository, revision, workflow and target environment produced the request.
Trust services need availability and recovery
Identity providers, certificate authorities and policy engines are operational dependencies.
If they fail, the system may need to:
fail closed
or:
use a bounded degraded mode
The correct behaviour depends on the action.
Reading public catalog data may tolerate cached policy.
Modifying production IAM should require current authorisation.
The architecture needs:
- high availability
- bounded caching
- explicit degraded modes
- monitoring
- tested recovery
- emergency access
Break-glass access should use a sufficiently independent trust path for the scenario it is intended to recover from.
It should be narrow, strongly authenticated, visible, tested and reconciled after use.
An emergency account that nobody can access is not secure recovery.
An emergency account used for daily administration is not emergency access.
Apply zero trust proportionately
Not every action requires the same assurance.
LOW-RISK ACTION
authenticated session
SENSITIVE ACTION
recent authentication
managed device
temporary elevation
DESTRUCTIVE ACTION
strong authentication
independent approval
audit
recovery verification
Zero trust should not become zero productivity.
If ordinary access requires repeated approvals, obscure errors and unpredictable delays, users will create unsafe workarounds.
A strong design provides:
- single sign-on
- role-based access
- clear elevation
- actionable denials
- automatic expiry
- self-service where risk permits
Security improves when the supported route is easier than the workaround.
Adopt by risk and measure progress
Zero trust does not need to begin as one enormous transformation programme.
A practical sequence is:
1. Inventory high-impact trust relationships.
2. Replace shared human and workload credentials.
3. Separate authentication from resource authorisation.
4. Apply temporary privilege to sensitive operations.
5. Add enforcement and evidence to critical journeys.
6. Measure revocation and degraded-mode behaviour.
7. Expand according to risk and blast radius.
Useful measures include:
- workloads with distinct identities
- permanent credentials remaining
- privileged-session duration
- revocation propagation time
- sensitive actions covered by explicit policy
- decisions with actionable reasons
- break-glass test success
- shared credentials discovered
- policy false-positive rate
The goal is not a percentage labelled “zero trust complete.”
It is measurable reduction in broad, durable and invisible authority.
A bfstore workload example
Suppose the order service calls the payment service.
The weak model is:
Both services run
inside the production cluster.
Therefore the request is trusted.
The stronger path is:
ORDER SERVICE
│
▼
WORKLOAD IDENTITY
│
▼
AUTHENTICATED CONNECTION
│
▼
PAYMENT AUTHORISATION POLICY
│
▼
DOMAIN VALIDATION
The network permits only expected communication.
The payment service verifies:
- the caller identity and issuer
- production environment
- permitted RPC
- current credential
- valid order reference
- permitted payment transition
- idempotency
No single layer carries the entire trust decision.
A bfstore human-access example
Suppose Mariam needs to investigate a production deployment.
Ordinary access provides:
development:
deploy and operate
production:
no standing administrator access
For an incident, she requests:
ProductionInvestigator
The system verifies:
- identity
- recent multi-factor authentication
- group membership
- managed device
- incident reference
The role provides:
- read-only Kubernetes access
- observability access
- deployment-history access
- no secret-value access
- no infrastructure deletion
The session expires automatically.
If intervention becomes necessary, a separate operator role is required.
Investigation authority does not silently become modification authority.
Questions I now ask
Subject
Which subject is acting,
and what evidence supports it?
Action
Which action on which
resource is requested?
Context
Which conditions matter,
and who controls those attributes?
Authority
What is the smallest useful
scope and duration?
Enforcement
Where is the decision
actually applied?
Evidence
What supports investigation
and detection?
Revocation
How quickly can authority
be reduced or withdrawn?
Failure
What happens when identity,
policy or recovery fails?
These questions turn zero trust into an architectural review rather than a branding exercise.
The mental model I am keeping
My earlier model was:
ZERO TRUST
never trust
always verify
The stronger model is:
CLAIMED IDENTITY
│
▼
EVIDENCE AND PROVENANCE
│
▼
IDENTITY ASSURANCE
│
▼
AUTHORISATION DECISION
│
┌───────────────┴───────────────┐
│ │
▼ ▼
ALLOW DENY
│
▼
BOUNDED AUTHORITY
│
┌──────┼──────────┐
│ │ │
▼ ▼ ▼
SCOPE DURATION CONDITIONS
│ │ │
└──────┼──────────┘
▼
ENFORCEMENT
│
▼
EVIDENCE
│
▼
REVOKE OR RENEW
Zero trust is not the absence of trust.
It is the refusal to let trust remain broad, invisible and permanent.
The architecture still trusts identity providers, keys, policy engines, cloud APIs and human operators.
It should know exactly which claims each component is trusted to make.
It should avoid converting one valid claim into universal authority.
A user authenticated through the corporate identity provider is a known claimant.
They are not automatically a production administrator.
A workload running inside the cluster has a known location.
It is not automatically authorised to read every secret.
A request travelling through an encrypted connection is protected in transit.
It is not automatically legitimate.
Zero trust becomes useful when identity evidence is explicit, authority is narrow, access is temporary, communication is protected, enforcement is real and important decisions leave evidence.
The marketing fog clears once the architecture stops asking:
Is this inside or outside?
and begins asking:
Who is acting?
What are they allowed to do?
Why is that decision valid now?
How far does the authority reach?
When does it end?
Those questions are less dramatic than declaring the network untrusted.
They are also far more useful when building systems that must survive compromised credentials, failed assumptions and ordinary human mistakes.