What to know
- Define access around specific resources and actions.
- Include service identities and enforcement inside the application architecture.
- Test failure, revocation, and exception paths alongside normal access.
Move the decision closer to the work
A person connects to a company network and opens a sensitive application. What actually justifies access to the records inside? A network connection answers where a request came from, but it does not fully establish which work the person should perform. Zero trust becomes useful when it turns that ambiguity into an explicit decision about a particular resource and action.
NIST SP 800-207 describes an architecture that grants no implicit trust based solely on network location or ownership. It separates authentication and authorization before access to an enterprise resource. That principle does not demand suspicion without limit. It asks organizations to use relevant evidence and policy rather than treating arrival inside a network boundary as a general authorization.
Write the policy as a business sentence
Consider a hypothetical engineering company whose contractors review drawings for individual projects. A useful policy says that an assigned contractor can read approved drawings for the current project during the engagement. That sentence identifies the subject, action, resource, and conditions. It is more precise than granting every contractor broad access to an internal file server.
Now examine exceptions. Can the contractor download an entire archive? Can a project manager add a new member? What happens when the contract ends but a review remains unfinished? Writing the intended behavior exposes business decisions that technology cannot make on its own. The goal is a policy that responsible owners can understand before engineers encode it.
Follow identity beyond the user interface
An application may call another service, which then queries storage. The user’s initial sign-in is only one identity relationship in that path. NIST SP 800-207A extends the discussion to application and service identities in cloud-native environments. The relevant access controls need to account for these relationships as well as network parameters and the person using the application.
In the drawing system, a preview service might need to read an approved document and create a temporary image. It does not automatically need the authority to delete the project or change membership. Give the service a defined job and examine how requests carry the necessary context. Otherwise a narrow user interface can sit above an unnecessarily powerful internal service.
Source: NIST SP 800-207A: Access Control in Cloud-Native Applications
Decide where a denial is enforced
For each policy, identify the component that makes the decision and the component that prevents the action. A policy document is not an enforcement point. Trace the ordinary request and any alternative path, including downloads, exports, administrative interfaces, and background jobs. Ask whether a caller can reach the same protected material without passing through the intended check.
This review can uncover a useful distinction in the hypothetical system: the web page may correctly hide old projects while an export job still reads them through a broad service account. The next step is to repair that specific path, not announce that the whole application is secure because its front door requires stronger sign-in. Authorization needs to follow the protected operation.
Source: NIST SP 800-207A: Access Control in Cloud-Native Applications
Design for the day a dependency fails
Access decisions depend on information and services that can become unavailable or stale. Decide what the application should do if it cannot retrieve an assignment, contact the policy service, or obtain current device information. Different resources may justify different responses. The team should understand whether a failure stops work, preserves a limited capability, or requires an approved exceptional process.
For the engineering company, emergency access to a safety-critical drawing may need a carefully designed procedure. That does not justify a permanent unrestricted account for all contractors. Name who can authorize the exception, what access it grants, how long it lasts, and how it will be reviewed. An exception is easier to control when it is designed before an outage.
Measure specific boundaries
A meaningful test changes one condition and observes whether the authorized behavior changes with it. Remove the contractor from the project, expire the engagement, or revoke the service identity in a controlled environment. Check the main interface and the less visible paths. Record how quickly the change takes effect and whether existing access survives in an unexpected place.
The result is a set of demonstrated controls around real work. It may use several products and architectural techniques, but its value comes from the boundaries they enforce together. A mature program can explain why access is allowed, where a denial is applied, and how authority ends. That is a more useful outcome than attaching the zero-trust label to an entire network.
Source: NIST SP 800-207A: Access Control in Cloud-Native Applications
Sources & further reading
- NIST SP 800-207: Zero Trust Architecture
- NIST SP 800-207A: Access Control in Cloud-Native Applications
Factual statements are grounded in the linked material. Interpretation and illustrative examples are Byte Watchr analysis. Vendor claims are identified as claims, rather than independent testing.
This article belongs to Byte Watchr’s launch collection. The edition date organizes evergreen coverage and does not imply historical publication. Actual publication is recorded above.
Corrections policy · About this byline
