Make access decisions around identities, resources, and context. Network location alone should not establish trust.
Published and sources reviewed: October 26, 2026 · Practical architecture guide
Start with the resource and the action
NIST’s Zero Trust Architecture centers protection on resources rather than assuming that being inside a network establishes trust. Translate that principle into explicit application decisions: who is requesting which action, on what resource, through which identity, and under what conditions?
Authentication establishes an identity claim. Authorization determines the permitted action. A successful sign-in should not imply access to every project, document, database, or administrative operation. Network controls remain useful layers, but they do not replace those decisions.
Human and workload identities
People need strong sign-in, appropriate device and session controls, timely offboarding, and narrowly scoped privilege. Workloads need identities tied to their actual service and environment. Prefer supported federation and short-lived credentials over distributing long-lived keys.
Separate everyday access, deployment authority, and emergency administration. Privileged elevation should have a defined purpose and duration. Keep a tested emergency path that does not depend entirely on the same service whose failure it must resolve.
Worked example: a deployment pipeline
Illustrative scenario: a build job exchanges its approved workload identity for permission to deploy one application to one environment. The identity provider and cloud role trust policy constrain the repository, branch or environment claims, audience, and permitted actions.
The cloud authorization layer checks the resulting request. Application code does not accept a model-generated claim of permission. Logs should connect the source change, pipeline run, issuing identity, target environment, and actual deployment outcome.
Test the boundaries
- Try the correct identity against the wrong environment.
- Try a valid identity with an unapproved action.
- Revoke access and verify that active sessions and dependent credentials behave as expected.
- Check whether inherited roles or group memberships expand the intended permission.
Review identities as a lifecycle: creation, approval, use, monitoring, change, and retirement. Useful measures include orphaned identities, unused privilege, long-lived credentials, and time to remove access.
Implementation checklist
- Identify each protected resource and action.
- Separate authentication from authorization.
- Use supported workload federation.
- Constrain audience and environment claims.
- Review inherited and privileged access.
- Test revocation and emergency recovery.
- Retire orphaned identities.