Security teams should move from network location as the trust signal to verified identity for both the user and the device. That means authenticating the user, validating device provenance with strong cryptographic proof, and granting access only to specific resources instead of the whole network. The goal is to reduce lateral movement, eliminate blanket access, and make trust decisions continuously at connection time.
Why device trust changes the access model
Replacing VPN-based perimeter trust means the network is no longer the proxy for trust. Infrastructure access should be granted only after the system confirms who the user is, what device is being used, and whether that device meets policy. That is the same zero trust logic described in NIST SP 800-207 Zero Trust Architecture: authenticate explicitly, assume the connection is untrusted, and make the decision at the resource boundary.
The practical shift is from broad network reachability to narrowly scoped access. Instead of placing an admin or engineer “inside” the environment through a tunnel, teams should expose only the specific systems, ports, and operations that the job requires. For infrastructure access, that usually means stronger session controls, tighter policy enforcement, and much smaller blast radius if credentials or endpoints are compromised.
Device trust also works best when the device is treated as an active input to authorization, not just a login checkbox. Current patterns rely on cryptographic device identity, device posture, enrollment provenance, and revocation capability. For workload and infrastructure access patterns that depend on attestation and strong identity proof, SPIFFE workload identity specification is a useful reference point for how strong identity can be bound to a runtime and verified before access is issued.
What has to replace the old VPN assumptions
The old model assumes the VPN boundary is a reliable trust boundary. It is not. Once a user is on the tunnel, broad lateral movement becomes much easier than it should be, especially if a single account is overprivileged or a device is unmanaged. A better model separates authentication, device verification, and authorization so that each access request can be decided on its own merits.
Teams should define the trust inputs with precision: identity of the operator, health and provenance of the device, and the exact target resource. That allows conditional access decisions such as allowing read-only access from a managed laptop while blocking high-risk administrative actions from an unverified endpoint. It also creates a clean place to revoke trust if the device falls out of compliance, is lost, or shows signs of compromise.
For infrastructure teams, the biggest implementation mistake is treating device trust as a replacement for network controls instead of a replacement for perimeter trust. Segmenting access, using least privilege, and issuing short-lived authorization are what make the model work operationally. The VPN may disappear, but the enforcement points do not.
Designing for narrower access and faster revocation
A device-trust model should reduce both standing access and the time a compromised endpoint remains useful. That means short-lived sessions, explicit reauthentication for sensitive actions, and fast deny decisions when posture changes. If the endpoint cannot prove provenance or current policy compliance, access should fail closed rather than fall back to coarse network trust.
This is where infrastructure access differs from ordinary application access. Admin pathways, cloud consoles, bastions, and privileged APIs are high-value targets, so trust must be validated at connection time and repeatedly when privilege changes. The operational goal is not just to block outsiders, but to prevent an authenticated insider session from becoming a lateral-movement beachhead.
For teams standardising on device trust, the control question is simple: can you prove that every session came from a known, managed, and attestable endpoint, and can you revoke that trust quickly enough to matter? If the answer is no, the access model is still behaving like perimeter VPN, just with more steps.
Risk and Threat Considerations
VPN-based trust concentrates risk in one broad access path. When an attacker steals credentials, compromises a device, or abuses a trusted tunnel, they often inherit far more reach than the original task required. Device trust narrows that blast radius, but only if posture checks, revocation, and resource scoping are enforced consistently.
Failure mechanism: A valid login combined with an unmanaged, compromised, or unverified device can still open a high-trust session if the policy only checks network presence or treats device checks as advisory. That creates a clear path for lateral movement and privilege abuse.
Impact: Attackers gain a smaller but much more dangerous foothold, because they can operate from what looks like an approved endpoint. The result is usually faster privilege escalation, harder-to-detect administrator activity, and greater exposure of infrastructure systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST Zero Trust (SP 800-207), CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | ZTA Principle: Verify Explicitly — Verify Explicitly | Device trust replaces perimeter assumptions with continuous verification at access time. |
| ZTA Principle: Least-Privilege Access — Least-Privilege Access | Infrastructure access should be narrowed from whole-network VPN reach to specific resources. | |
| Recommendation — Authenticate the user, verify device posture, and enforce resource-specific policy before granting access. Scope each session to the minimum infrastructure resources required for the task. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Device-trust access depends on protecting the credentials and tokens used to prove identity and device state. |
| NHI-04 — Least Privilege and Access Control | Narrowing VPN trust requires reducing standing access and limiting what a trusted device can reach. | |
| Recommendation — Use short-lived credentials and rotate or revoke them quickly when endpoint trust changes. Limit infrastructure sessions to specific roles, resources, and actions. | ||
| CIS Controls v8 | 6 — Access Control Management | Replacing VPN trust with device trust is an access-control design change centered on authorization scope. |
| 5 — Account Management | Device trust depends on strong handling of privileged and administrative accounts used for infrastructure access. | |
| Recommendation — Restrict administrative access to approved devices and tightly scoped resources. Review and disable unnecessary privileged accounts that could bypass device-based controls. | ||
| NIST CSF 2.0 | PR.AC — Access Control | The model strengthens access control by verifying identity, device, and authorization before connection. |
| Recommendation — Enforce identity- and device-based access decisions for sensitive infrastructure. | ||
| MITRE ATT&CK | T1021 — Remote Services | VPN and remote admin access are common pathways for initial foothold and later movement. |
| Recommendation — Harden and monitor remote access paths to reduce abuse of trusted administrative channels. | ||
Practitioner Guidance
What to prioritise: Start with the infrastructure paths that create the most blast radius, such as cloud consoles, bastions, orchestration planes, and break-glass access. Those are the places where device trust should be strictest and where a VPN-style fallback causes the most damage.
What to verify: Make sure the control can distinguish a managed, attested device from a merely logged-in user, and that it can revoke access when the device posture changes. A trust model that cannot be removed quickly is not a trust model, it is just delayed perimeter access.
Practitioner takeaway: Device trust works when it turns infrastructure access into a series of narrow, revocable decisions, not when it simply adds another gate before the same broad network reach.
Related resources from NHI Mgmt Group
- How should security teams replace VPN trust with zero trust access controls?
- How should security teams replace VPN access with identity-based controls?
- How should security teams implement identity-aware proxy controls without recreating VPN-style broad access?
- How should security teams choose between network-level access tools and application-layer zero trust controls?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
