Yes, when the native platform provides sign-in and basic directory functions but cannot govern entitlements across the whole estate. The key is co-existence, not duplication. Keep authentication where it works best, then add a governance layer that can reach non-native applications, service accounts, and other identities the core directory cannot manage well.
Why separate authentication from governance?
Authentication and governance solve different problems. Authentication proves who or what is signing in; governance decides what that identity should be allowed to do, whether that access is still appropriate, and whether it needs review or removal. In larger environments, one platform rarely does both well across employees, contractors, applications, service accounts, and SaaS tools.
The practical reason to split the functions is coverage. A native login platform may be strong at sign-in, single sign-on, and basic directory services, while a governance platform is better at entitlement discovery, access reviews, and lifecycle control across systems it does not own. That division becomes useful when choosing an identity provider and deciding what must remain in the core authentication stack versus what needs broader governance reach.
This is also why organisations should not treat governance as a duplicate directory. The goal is to add control over access that the native platform cannot see natively, including non-native applications, privileged paths, and access governance for connectors, roles, and recertification across the estate.
What the split should cover in practice
A useful split starts with a stable authentication source, then layers governance on top. The authentication platform should remain the system of record for sign-in, federation, MFA, and primary account lifecycle where it is strongest. Governance should then ingest identities and entitlements from across the environment so it can make decisions about access that are broader than any single application or directory.
That usually means the governance layer must reach places the login system cannot govern on its own, such as ERP, finance, engineering tools, legacy apps, cloud roles, and service or shared accounts. If the governance tool cannot connect to those estates, then the split has little value. A platform may authenticate well but still leave the organisation blind to accumulated privilege, orphaned access, or stale entitlements.
For workforce sign-in, the authentication layer should still be designed around strong proofing and phishing-resistant methods. NIST guidance on digital identity remains the right reference point for that side of the house, especially where the organisation is choosing between passwords, MFA, passkeys, or federated sign-in. The governance layer should not weaken that control model; it should depend on it and extend oversight beyond it with NIST SP 800-63 Digital Identity Guidelines.
When does the split become the right operating model?
The split makes the most sense when the environment has heterogeneous identity sources, many disconnected applications, or mixed human and non-human access. It is also a strong fit when the business needs stronger review, certification, and segregation of duties than the core sign-in platform can provide. In those environments, authentication and governance are adjacent controls, not interchangeable ones.
The decision becomes clearer when access can outgrow the directory. If teams can create entitlements in SaaS apps, assign cloud roles, or provision service credentials outside the main directory, then authentication alone will not prevent privilege sprawl. Governance becomes the control that identifies those paths, reconciles them, and helps remove access that no longer belongs. That is the same pattern behind mature identity programmes and IGA platform selection.
Co-existence is usually better than replacement. Organisations should keep the platform that already performs authentication reliably, then add governance where it materially improves oversight. The mistake is trying to make one product cover every identity function equally well, which often leads to weak coverage in both sign-in and entitlement control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Covers workforce sign-in strength, MFA, and federation choices central to authentication. |
| Recommendation — Use NIST 800-63 to set authenticators and assurance requirements for sign-in and federation. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Applies to employee and admin authentication in the shared sign-in platform. |
| IA-9 — Service Identification and Authentication | Covers service and workload identities that governance often needs to observe beyond human sign-in. | |
| AC-2 — Account Management | Maps to lifecycle control over accounts and access that governance must review across systems. | |
| Recommendation — Apply IA-2 to authenticate organizational users with strong, verifiable methods. Apply IA-9 to authenticate services and workloads that need non-human access control. Use AC-2 to govern account provisioning, review, and deprovisioning across the estate. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Directly supports separating authentication from broader access governance. |
| A.5.18 — Access rights | Covers granting, reviewing, and removing access rights across the estate. | |
| A.8.5 — Secure authentication | Supports the authentication layer's job of proving identity securely. | |
| Recommendation — Implement A.5.15 to define and enforce access control policy across systems. Apply A.5.18 to review and revoke access rights on a defined schedule. Use A.8.5 to secure authentication mechanisms and protect sign-in flows. | ||
| CIS Controls v8 | CIS-5 — Account Management | Matches the need to manage access lifecycle and remove stale access at scale. |
| CIS-6 — Access Control Management | Supports governance over permissions and the separation between sign-in and authorization. | |
| Recommendation — Use CIS-5 to inventory, provision, review, and remove accounts and access. Use CIS-6 to enforce least privilege and review high-risk access paths. | ||
Practitioner Guidance
What to prioritise: Keep authentication and governance as separate control planes, but make sure they share authoritative identity and entitlement data. If the governance tool cannot see the full access surface, it is not solving the core problem.
What to verify: Check whether the governance layer can actually reach non-native applications, cloud entitlements, privileged accounts, and service identities, not just the same directory already covered by the login platform. If it only audits what the source system already knows, the split adds limited value.
Common mistake: Treating identity governance as a second directory or assuming the sign-in platform can provide complete access review. Authentication confirms entry, but governance is what exposes overreach, stale access, and disconnected privilege paths.
Practitioner takeaway: Use one platform to authenticate and another to govern only when each has a clear control boundary, because the winning pattern is broad access visibility on top of strong sign-in, not duplicated functionality.
Related resources from NHI Mgmt Group
- How should security teams use IAST and RASP in NHI governance?
- Should organisations prioritise external exposure or internal credential governance first?
- Should organisations use one governance workflow for humans, NHIs, and AI agents?
- What breaks when organisations try to use one identity suite for every governance problem?