They should live in the identity system whenever possible. Identity-backed access lets joiners, movers, and leavers follow the same lifecycle as other enterprise access, while a network-device model forces manual cleanup and creates a second authority that can easily drift from source-of-truth records.
Why the Source of Remote Access Authority Matters
Remote access permissions belong with the identity layer because access is granted to a person, vendor, or service account, not to a box on the network. When the identity system is the authority, provisioning, MFA, access review, and deprovisioning all use the same record. That makes the access path easier to govern, audit, and revoke when roles change.
When the network device holds the permissions, it becomes a parallel source of truth. That can work for a narrow technical exception, but it usually creates duplicate records, weak ownership, and manual cleanup debt. A remote access control plane should follow the same lifecycle as the identity that uses it, not a separate device-specific database.
Identity-backed remote access is also easier to align with NIST SP 800-207 Zero Trust Architecture, because the decision is based on verified identity and context rather than implicit trust in the device boundary. That matters most when access must be updated quickly across many users, contractors, or support teams.
When a Network Device Becomes the Wrong Authority
A network-device model often starts as convenience, but it tends to drift from the enterprise joiner-mover-leaver process. If the user leaves, the account can remain active until someone remembers to remove it. If the user changes teams or vendors, the old device-side permission may survive because no one updated the second system.
This is where remote access becomes an entitlement problem, not just a connectivity problem. The device may enforce the tunnel, but the identity system should decide who is eligible, under what conditions, and for how long. That is why good remote access design usually pairs the identity source with conditional access, strong authentication, and explicit review of standing access.
For practitioners comparing control models, IAM and IGA Basics is a useful way to keep the access decision, the entitlement lifecycle, and the review process in one place. The same principle applies whether the access target is a VPN, ZTNA gateway, remote admin portal, or third-party support channel.
Some environments still keep a narrow exception on the device side for emergency break-glass access or tightly scoped administrative roles. Even then, the exception should be owned, time-bound, logged, and reconciled back to identity governance so that the network device does not become a permanent shadow directory.
What Good Remote Access Governance Looks Like
The best pattern is to treat the identity system as the source of truth and the network device as the enforcement point. Identity owns eligibility, group membership, MFA status, and lifecycle events. The device consumes that policy and translates it into session admission, posture checks, or route enforcement.
This design gives you better operational control because changes happen once and propagate everywhere. It also reduces the chance that one device silently diverges from the enterprise record. For remote access at scale, that difference is usually more important than the convenience of local rule creation.
Remote access design also benefits from shared visibility across access methods. A team that wants to understand remote support exposure, vendor paths, and dormant accounts should map the same identities across VPN, admin portals, and privileged session tooling. Remote Access Identity Guide and Privileged Session Management Guide both support that control mindset, especially where the session itself needs monitoring or recording.
Where the remote access path touches service accounts, APIs, or support automation, the same source-of-truth principle still holds, because the lifecycle and revocation problem does not disappear just because the actor is non-human. The governing question remains: who owns the access, how is it approved, and how is it removed when the need ends?
Risk and Threat Considerations
Putting remote access permissions on a network device increases exposure if identity records, offboarding, and device policy are not kept in lockstep. The main risk is stale or duplicated access that survives role changes, contractor exits, or emergency exceptions longer than intended.
Failure mechanism: The network device becomes a second authority, so revocation depends on manual cleanup or brittle synchronization rather than a single governed lifecycle. Attackers and insiders benefit when that drift leaves a valid path open after the identity record should have been disabled.
Impact: Unauthorized remote entry, delayed offboarding, and harder audits. In practice, that can widen blast radius, obscure ownership, and make it much harder to prove that access was removed on time.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Remote access permissions depend on provisioning and removal of eligible accounts. |
| IA-2 — Identification and Authentication (Organizational Users) | Remote access should hinge on verified identity before access is granted. | |
| AC-6 — Least Privilege | Remote access should be limited to the minimum access needed for the role. | |
| Recommendation — Centralize remote access eligibility in account lifecycle controls and revoke it on role change or exit. Require strong user authentication before any remote access path is opened. Constrain remote access rights to the minimum set needed for the user’s function. | ||
| NIST Zero Trust (SP 800-207) | ZR — Zero Trust Architecture | Remote access should be based on continuous verification, not network location. |
| Recommendation — Treat the identity system as the policy source and enforce access at the connection point. | ||
| CIS Controls v8 | CIS-5 — Account Management | Remote access permissions need centralized provisioning, review, and deprovisioning. |
| Recommendation — Manage remote access through a single account lifecycle process and remove stale access quickly. | ||
Practitioner Guidance
What to prioritize: Make the identity system the owning system for remote access eligibility, and let the network device enforce that decision. If the device must keep a local exception, require a named owner, explicit expiry, and a documented reconciliation path back to identity governance.
What to verify: Confirm that revocation in the identity system actually removes access from every remote entry point, including VPN, ZTNA, support portals, and privileged access tools. If one path can still admit the user after deprovisioning, the control is incomplete.
Common mistake: Treating a network appliance as the place to manage people. That usually works until the first urgent offboarding, vendor exit, or incident review, when the duplicate authority becomes the problem you have to untangle.
Practitioner takeaway: Remote access should be governed where the identity lives and enforced where the connection terminates; splitting authority may look simpler at deployment time, but it usually creates the harder security and lifecycle problem later.
Related resources from NHI Mgmt Group
- What breaks when organisations treat device biometrics as proof of identity for remote access?
- Why do remote access programs need identity verified application access instead of broad network access?
- How should security teams handle device posture and network access when remote devices need to connect from unmanaged environments?
- What is the difference between device posture checks and network segmentation in a remote access environment?