Start with the resource being requested
NIST SP 800-207 shifts attention from static network perimeters toward users, assets, and resources. It explicitly rejects implicit trust based solely on network location or asset ownership. This does not mean every interaction must be designed from scratch. It means access decisions need an appropriate basis beyond being inside a subnet or using company equipment. Identify the protected resource and the proposed action before deciding what authentication, authorization, and contextual information are necessary.
Separate identity from permission
Authentication establishes an identity; authorization determines what that identity may do. Apply this distinction to people, service accounts, devices, and automated workloads. A valid login should not imply permission to administer every connected system. Document how access is granted, reviewed, and removed. Shared dependencies matter too: if a policy or identity service becomes unavailable, the organization needs a deliberate response rather than an undocumented fallback that exposes resources or interrupts essential work unpredictably.
Plan migration around real workflows
Inventory applications, callers, and data paths before changing enforcement. Begin with a bounded service and test both permitted and denied requests. Include account changes, expired credentials, and unsupported device states. The intended controls must remain understandable to operating teams and users. Avoid equating zero trust with a single product purchase or assuming that segmentation alone implements the architecture. CISA’s buyer guidance reinforces the importance of evaluating actual security capabilities and maintaining responsibility after procurement.
Retain evidence and revisit decisions
Measure unnecessary privilege, access failures, exceptions, and time required to revoke permissions. Review whether controls are enforced consistently across remote and local paths. Keep configuration and policy changes traceable without collecting sensitive content unnecessarily. Future network architectures may create additional access patterns, but the fundamental question remains the same: is this actor permitted to perform this action on this resource under the current conditions? A useful zero-trust program makes that decision enforceable and operationally accountable.