IT teams should use a domainless identity model that can authenticate users through modern federation protocols and update access from anywhere. The goal is to keep the source of truth available outside the office, so administrators can grant, change, or revoke application access immediately without needing direct on-prem directory access or a VPN session.
Why domainless access control changes the remote-work operating model
A domainless model works because access decisions are no longer trapped behind the corporate network. Instead, identity, authentication, and authorization stay reachable from any location, so IT can provision or remove SaaS access as soon as a user’s status changes. That matters most when workers are distributed, contractors move quickly, or the business cannot tolerate waiting for a VPN connection just to update entitlements.
The practical shift is that the directory becomes an identity source, not a place users must reach. Modern federation lets the SaaS app trust the identity provider, while access policy determines who can get in. That design reduces dependence on network reachability and makes access governance a control-plane problem rather than a remote connectivity problem.
For teams comparing patterns, the important question is not whether users can log in from home. It is whether the access lifecycle can be administered immediately, consistently, and with enough assurance to support joiner, mover, and leaver changes without an office-bound workflow. A system that still depends on a VPN session for directory edits is usually carrying an unnecessary operational bottleneck.
How federation and modern identity providers support anywhere administration
Modern federation protocols let the SaaS application rely on a central identity provider for authentication, while the app enforces its own authorization rules based on roles, groups, or attributes. That arrangement is what allows administrators to change access from outside the office without exposing the directory itself to the internet. The remote administrator is changing policy or entitlements, not directly touching every SaaS tenant by hand.
This is also where the distinction between authentication and authorization matters. Authentication proves who the user is; authorization decides what the user may do in the SaaS app. In a domainless model, those two layers stay logically separate, which makes it easier to enforce least privilege, make access reviews repeatable, and avoid hard-coding network location into access decisions.
Where teams need a useful reference point for the control model, IAM and IGA Basics explains the governance mechanics behind provisioning, access reviews, and entitlement lifecycle, while Authorisation Models Guide helps teams choose the right authorization model for SaaS access. For the network side of the pattern, NIST’s Zero Trust Architecture guidance reinforces that access should be verified and constrained per request, not assumed because a user is on a trusted network.
What good SaaS access control looks like for a distributed workforce
Good practice is to treat SaaS access as a lifecycle process, not as a network exception. That means the source of truth for user status, role assignment, and app entitlement changes must be reachable to the admin team at all times, and access changes should propagate without waiting for on-prem connectivity. The goal is fast, auditable change control, not just successful sign-in.
In practice, this usually means three things: centralize identity governance, federate SaaS authentication, and separate emergency admin access from everyday user access. If the business still relies on VPN-bound changes for a routine entitlement update, the control is too brittle for remote work. If it relies on manual app-side edits with no governance trail, it is too easy to drift into inconsistent permissions.
Teams that want to see the broader access pattern in context can use Remote Access Identity Guide for the VPN-to-ZTNA transition, and Just-in-Time Access and Zero Standing Privilege Guide for reducing permanent admin exposure. On the standards side, NIST SP 800-207 Zero Trust Architecture is the strongest external reference for the verify-before-trust approach that underpins this operating model.
Risk and Threat Considerations
When access changes depend on a VPN-bound directory path, the business inherits a delay window where joiners may wait too long, leavers may keep access too long, and urgent revocations can be blocked by connectivity or support availability. That is an access governance risk even before you consider abuse by an attacker.
Failure mechanism: The control plane is reachable only through a network path that may be unavailable, so entitlement updates, MFA resets, or deprovisioning actions can be delayed, manually bypassed, or performed inconsistently across apps.
Impact: Stale access persists longer than intended, revocation becomes less reliable, and compromised accounts or excess privileges have more time to be used against SaaS data and business processes.
The threat angle is especially important when SaaS access is tied to remote workers, contractors, or privileged administrators. If the path to change access is slower than the path to use it, attackers and insiders both benefit from the delay. That is why incidents involving stolen credentials and unattended remote access remain so damaging, and why SonicWall VPN Mass Breach via Stolen Credentials, Change Healthcare breach 2024, and Colonial Pipeline ransomware attack are useful reminders that remote access weaknesses often become business-wide incidents.
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 and NIST Zero Trust (SP 800-207) set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Federated SaaS access still depends on strong user authentication. |
| AC-2 — Account Management | The question is about granting, changing, and revoking SaaS access. | |
| AC-6 — Least Privilege | Remote SaaS access should be limited to the minimum necessary entitlements. | |
| Recommendation — Use IA-2 to enforce strong user authentication before SaaS access is granted. Use AC-2 to centralize account lifecycle changes and rapid revocation. Use AC-6 to restrict SaaS permissions to the minimum required access. | ||
| NIST Zero Trust (SP 800-207) | ZT-07 — No Implicit Trust | Domainless remote access depends on verifying each access request, not trusting location. |
| Recommendation — Apply zero-trust principles to verify every SaaS access request independently. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | SaaS entitlement control is an access-control governance problem. |
| Recommendation — Define and enforce access control rules for SaaS through centrally governed policies. | ||
Practitioner Guidance
What to prioritise: Put entitlement change speed, revocation reliability, and auditability ahead of preserving legacy VPN-era admin workflows. If a directory edit still requires an office network path, the process is already too fragile for distributed operations.
What to verify: Confirm that administrators can change SaaS access through a federated control path from outside the corporate network, that changes propagate quickly, and that every grant, removal, and privilege change leaves a reviewable trail. Validate this for both standard users and exception cases such as contractors or privileged access.
Practitioner takeaway: The right design is the one that lets identity governance operate independently of office connectivity, because access control should stay available when the VPN is down, the user is remote, or a revocation must happen immediately.
Related resources from NHI Mgmt Group
- How should security teams govern access for remote workers without relying on the office perimeter?
- How should security teams manage privileged access for vendors and remote users without relying on VPN access?
- How should IT teams automate access reviews and lifecycle changes across SaaS and custom apps without relying on manual oversight?
- How should security teams secure remote production workflows without relying on always-on VPN access?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
