Teams should govern access through authenticated identity, device trust and context rather than network location. The practical shift is to treat every access request as untrusted until the identity, device and policy conditions are verified, including for cloud apps, connected devices and machine-to-machine connections.
Why “no reliable perimeter” changes the access model
A perimeter-based model assumes the network can tell you something trustworthy about the requester. When that assumption fails, access decisions have to move up the stack to the identity, device and policy layers. That means the control point becomes the request itself, not the subnet, VPN or office location.
The key operational shift is that trust is no longer inherited from being “inside.” Teams need an access model that can authenticate the requester, evaluate the device posture or trust state, and then apply policy consistently across SaaS, internal apps, APIs and machine-to-machine traffic.
This is why zero-trust style access control is less about a brand name and more about replacing location trust with explicit verification. The practical question is not where the request came from, but whether the request is eligible right now.
What teams should govern instead of network location
Teams should govern access through authenticated identity, device trust and context-aware policy. In practice, that means access rules should consider who or what is requesting, whether the device or workload is known and trusted, and whether the context matches an approved use case, sensitivity level or risk threshold.
For human users, that usually means strong authentication, conditional access and least privilege. For applications, services and automation, it means treating the calling workload as an identity-bearing actor with its own permissions, lifecycle and trust boundaries. The same logic applies whether the request comes from a browser, an endpoint, a cloud workload or an API client.
Location still has value as one signal, but it should be only one input among several. If network location becomes a hard dependency, users and systems will route around it with tunnels, shared credentials or broader access than necessary.
How to make the model usable at scale
Governance works when the policy is specific enough to automate but still narrow enough to avoid blanket exceptions. A good access model defines what must be true at decision time, such as verified identity, compliant device state, approved application, acceptable risk score, and valid purpose or transaction context.
For cloud apps and remote work, this usually means centralised policy enforcement with step-up checks when conditions change. For machine-to-machine connections, it means using explicit authentication and tightly scoped authorisation rather than assuming that traffic from a trusted network segment is acceptable by default. OAuth 2.0 authorization for machine-to-machine access is one common pattern when the caller is a workload rather than a person.
Teams also need to govern exceptions. If a team cannot express the policy in terms of identity, device and context, the exception will usually become a permanent back door. That is a governance failure, not an implementation detail.
Risk and Threat Considerations
When network location is treated as proof of trust, attackers can exploit the weakest path into the environment and then move laterally with far too little friction. The most common failure mode is overbroad access after initial compromise, especially where remote access, shared credentials or legacy VPN trust are still treated as implicit approval.
Failure mechanism: A compromised account, stolen token or trusted device can satisfy a perimeter rule even when the requester should be challenged again. Once inside, the attacker can blend in with normal traffic, expand access and reach data or systems that were never meant to be exposed through the same trust boundary.
Impact: The blast radius of a single compromise grows quickly, because the perimeter no longer contains the decision. Sensitive cloud apps, internal services and machine connections all become reachable if they rely on location instead of explicit identity and context checks.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST Zero Trust (SP 800-207), NIST CSF 2.0, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Core model for replacing perimeter trust with explicit verification |
| Recommendation — Apply zero trust principles to evaluate identity, device and context on every access request. | ||
| NIST CSF 2.0 | PR.AA-05 — Protective Technology | Supports access enforcement across remote, cloud and distributed environments |
| Recommendation — Implement protective access controls that verify request conditions before granting access. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | User access must be authenticated before trust can be granted |
| IA-9 — Service Identification and Authentication | Machine-to-machine access depends on authenticating workloads and services | |
| AC-6 — Least Privilege | Least privilege limits blast radius when perimeter trust is absent | |
| Recommendation — Require strong authentication for organizational users before allowing access. Authenticate services and workloads explicitly before allowing system-to-system access. Limit each identity to the minimum access required for its current task. | ||
| OWASP ASVS | V8 — Authorization | Contextual access decisions depend on robust authorization controls |
| V10 — OAuth and OIDC | Modern identity-centric access patterns depend on federation and token-based access | |
| Recommendation — Verify that authorization decisions are explicit, consistent and least-privilege aligned. Use federated authentication and scoped tokens to enforce request-time access decisions. | ||
Practitioner Guidance
What to prioritise: Start by mapping the access paths that still rely on network trust, then rank them by blast radius. The highest-value fixes are usually the paths that reach sensitive data, administrative functions or machine-to-machine integrations.
What good looks like: Access decisions are made at request time using verified identity, device trust and policy context, with consistent enforcement across user, service and workload access. A user or workload should not gain access simply because it is on a “safe” network.
Common mistake: Replacing the perimeter with a VPN while leaving the authorisation model unchanged. That preserves old trust assumptions and often makes the real control gap harder to see.
Practitioner takeaway: The goal is not to remove trust, but to make trust explicit, time-bound and decisioned per request, so compromise of one path does not automatically become compromise of the whole environment.