Zero Trust Architecture: A Resource-by-Resource Implementation Plan

Plan zero-trust access for people and workloads with resource-level policy, enforceable boundaries, revocation tests, outage behavior, and controlled emergency access.

Start with a resource and an access decision

Zero trust does not mean that networks have no boundaries or that an attacker is known to be inside your systems. It means that network location or organizational ownership alone is not sufficient evidence for granting access. Network controls still matter, alongside identity, authorization, resource sensitivity, and relevant context.

That distinction follows NIST SP 800-207. Treating possible compromise as a design condition helps limit what a stolen credential or compromised workload can reach. It is not a finding that a specific organization has been breached.

Start with one important resource, such as a customer-support API, payroll export, or production administration endpoint. Identify who needs which action, what information the action exposes, and where the decision is actually enforced. Buying an access proxy before answering those questions can preserve broad permissions behind a different login screen.

This guide is an implementation planning aid. It does not certify a system's security or establish compliance with a particular legal or audit requirement.

Separate identity, policy, and enforcement

Authentication establishes an identity with a particular level of assurance. Authorization decides what that identity may do. Enforcement prevents a request from reaching or operating on the protected resource when the required conditions are absent.

NIST's implementation architecture distinguishes a policy engine, a policy administrator, and a policy enforcement point. The engine determines access; the administrator carries the decision into effect; the enforcement point controls the connection to the resource. These are logical responsibilities, not a requirement to buy three products.

The simplified diagram groups policy decision and administration together. Solid arrows carry requests. The dashed arrow carries the access decision. Identity issuance, context collection, and audit delivery are omitted to keep the enforcement relationship visible.

Do not let a gateway decision replace object-level authorization inside an application. An authenticated support agent may be allowed to call the API but still be prohibited from opening another tenant's record. Prevent bypass through a direct backend address, a legacy endpoint, an export job, or a broad database credential.

“Continuous verification” also needs an implementation definition. It does not require sending every packet to a central policy service. Specify when credentials and authorization are checked, which signals trigger reevaluation, how long decisions may be cached, and how access is terminated.

Give humans and workloads different credential paths

For human access, connect identity lifecycle events to resource permissions. Joining a team, changing roles, losing a device, and leaving the organization should produce testable changes in access, not merely changes in a directory entry.

Use authentication strength appropriate to the resource. Consider phishing-resistant authentication for sensitive access, together with enrollment and recovery controls that do not quietly bypass it. NIST SP 800-63B-4 explains phishing resistance and authenticator requirements. A manually entered one-time code is not phishing-resistant merely because it is a second factor.

Services need their own identities. An overnight export job cannot complete an interactive employee MFA prompt, and borrowing a developer's credential hides accountability. Use platform-supported workload identity, scoped roles, and short-lived credentials where suitable. Validate issuer, intended audience, identity, and permissions as applicable to the credential format.

SPIFFE is one approach to portable workload identity. It supplies an identity foundation, not the application's business authorization policy. A mutually authenticated connection still needs a decision about which operation and resource the calling service may use.

Short-lived credentials reduce the lifetime of a leaked credential, but do not cure excessive permission or guarantee immediate revocation. Test issuance, renewal, clock handling, and the behavior of existing connections after an identity is disabled.

Worked policy: customer-support access

This hypothetical example concerns a support application containing confidential customer records. It is not a claim about an Ampity implementation.

Support staff may read cases assigned to their customer scope. A background summarization service may read approved case fields but may not export attachments or update account permissions. Production administration uses a separate privileged role and approval path.

| Request or condition | Resource-specific decision | | --- | --- | | Support agent, valid role, permitted customer, acceptable device evidence | Allow the authorized case operation; record identity, resource, action, policy version, and outcome | | Valid employee identity, different customer's case | Deny. Membership in the support organization is not cross-customer permission | | Required device evidence is absent or indicates compromise | Deny access to confidential records and direct the person to a separate remediation route. Read-only access still exposes data | | Summarization workload with valid identity | Allow only the approved fields and operations; deny bulk attachment export and account administration | | A request tries to reach the backend without the enforcement path | Reject through backend authentication, authorization, and network restrictions, as appropriate to the deployment | | Privileged production change | Require the separate privileged identity and approval conditions; do not inherit permission from ordinary support access |

Write negative tests from this table, including attempts by legitimate identities with the wrong resource or action. Test account and role removal, revoked sessions, missing device evidence, and credentials for a different audience. Keep policy fixtures free of real customer data.

The result is not a single trust score. It is a set of understandable decisions that owners can explain and testers can challenge.

Design failure behavior before tightening access

An identity or policy dependency can fail. So can the signal source used to decide whether a device is healthy. Distinguish “known unacceptable” from “unknown because telemetry is unavailable,” then define the permitted response for each resource.

| Failure | Decision to document and test | | --- | --- | | Identity provider cannot issue or renew credentials | Define whether existing sessions remain usable under their established limits. Do not silently extend expired credentials | | Policy evaluation is unavailable | For sensitive actions, deny or pause when required authorization cannot be established. Any bounded use of a previously valid decision needs explicit resource-owner approval | | Cached authorization outlives a role change | Define cache expiry and revocation propagation. Measure the longest observed interval until every relevant enforcement point rejects access | | Enforcement proxy or sidecar fails | Test redundancy and recovery without introducing an unguarded bypass route | | Audit destination is unavailable | Decide whether durable local buffering is sufficient or the action must pause; bound storage and make evidence loss visible | | A new policy blocks legitimate work | Roll back the policy version after review, while retaining the enforcement boundary and reviewing any permissions the old version would restore |

Availability and confidentiality can conflict. A public information endpoint and a payroll export should not inherit the same fallback merely for operational convenience. For essential workflows, design a restricted alternative before an outage. An emergency process is not permission to disable authorization for everyone.

Session revocation deserves its own test. Disabling an account in the identity provider may not invalidate an application's local session, an already issued token, or a long-lived connection. Record each relevant lifetime and revocation mechanism. Exercise them across gateways and applications, not just at the login screen.

Make emergency access controlled and observable

An emergency administrator needs a path that can survive the specific failure it is meant to repair. If every recovery step depends on the unavailable identity provider, the runbook is circular.

Design emergency credentials and authentication around the target platform's supported mechanisms. Limit their purpose, protect their custody, alert on use, record the reason, and review the actions afterward. Rehearse recovery with authorized responders. Rotate or replace exposed credentials and remove temporary grants after the incident according to the platform's procedures.

Microsoft's emergency-access guidance for Entra ID gives a concrete provider-specific example. Its settings are not a universal recipe for every cloud or identity system. The applicable principle is to test independence from failed dependencies while retaining strong control and monitoring.

Exceptions need an owner and a review condition. An undocumented legacy account with permanent broad access is not an emergency-access design.

Roll out by resource, with evidence at each step

Inventory real access paths before enforcing a new policy. Include employees, contractors, service accounts, CI jobs, scheduled tasks, and recovery operations. Observation helps discover dependencies, but observed traffic is not automatically legitimate or a complete record of rare tasks.

Where the platform supports it, use report-only policy evaluation to identify likely denials. That mode cannot prove enforcement works. Follow with authorized positive and negative tests, then a controlled rollout whose owner can respond to unexpected denials.

For each resource, keep a small acceptance record:

• The protected operations, identities, tenant or data scope, and decision owner.
• The enforcement locations and evidence that alternate access paths are blocked.
• The source, freshness, and failure behavior of each required context signal.
• Successful credential renewal, role removal, session termination, and revocation tests.
• Tested policy rollback, dependency outage, and emergency-access procedures.
• Access-decision evidence that supports investigation without logging secrets or unnecessary sensitive payloads.

Review denial patterns, exception growth, revocation delay, and user recovery effort after rollout. Excessive friction is evidence to investigate, not a reason to promise that security has no operational cost.

NIST SP 1800-35 provides implementation examples that can inform this design. Adapt them to your resource risks and existing systems. A zero-trust label does not replace threat modeling, application security, incident response, backups, or a qualified review of applicable obligations.

Bring the resource inventory and acceptance record to a cloud security and compliance review. The useful outcome is a scoped set of identity, enforcement, logging, and recovery controls with evidence and owners, not a blanket promise of compliance.