The main break point is purpose mismatch. Provisioning systems are optimized for onboarding and deprovisioning, while governance requires modelling actual access relationships across connected and disconnected systems. When one platform is forced to do both, oversight becomes incomplete, controls are harder to enforce, and teams struggle to answer basic questions about privilege, compliance, and policy violations.
Why Provisioning and Governance Pull in Different Directions
Provisioning is built for speed and repeatability: create accounts, assign roles, revoke access, and keep workflows moving. Governance is built for oversight: understand who has access, why they have it, whether it is still justified, and whether policy is being violated across systems that do not all behave the same way. When both jobs are forced into one platform, the result is usually a compromise that is fast enough for onboarding but too shallow for control assurance.
That mismatch matters because governance depends on modelling real access relationships, not just directory records. A platform can say that an identity exists and that a role was assigned, yet still miss indirect entitlements, shared credentials, disconnected SaaS permissions, or machine-to-machine access paths. For NHI-heavy environments, that gap is especially dangerous because the highest-risk access often sits outside the neat lifecycle that human-oriented provisioning tools were designed to manage. NHIMG has shown that credential rotation and visibility gaps remain major drivers of compromise, which is why lifecycle depth matters beyond simple ticket automation.
Provisioning and governance can coexist operationally, but they do not solve the same problem, and teams often discover that only after access sprawl has already made review and remediation expensive.
How the Split Shows Up in Day-to-Day Operations
In practice, the combined platform tends to optimise for the easiest data source, usually the identity store that owns account creation. That works well for joins and leaves, but it breaks down when teams need evidence of actual effective access across applications, cloud services, APIs, and delegated relationships. Governance needs correlation, reconciliation, and policy evaluation across systems that may not share the same schema, timing, or ownership model.
That is why many programmes end up with brittle controls. A role may be provisioned correctly, but the real exposure lives in inherited group membership, stale tokens, OAuth grants, or service accounts that are invisible to the provisioning workflow. Current guidance suggests that governance must verify entitlement state separately from the act of issuance, because “access granted” is not the same as “access justified.” The NIST Cybersecurity Framework 2.0 is useful here because it separates identity governance, protection, detection, and recovery concerns rather than treating access administration as a single control domain. For NHI lifecycle depth, the NHI Lifecycle Management Guide is a better lens than a provisioning-only workflow.
- Provisioning answers who should get access now.
- Governance answers whether that access still makes sense across all connected systems.
- Provisioning can be synchronous; governance often has to be asynchronous and evidence-driven.
- Provisioning can be automated end to end; governance still needs exception handling, attestation, and policy interpretation.
When one platform tries to do both, the weakest integration point usually becomes the control point, and that is where blind spots, false confidence, and manual workarounds accumulate.
Where the Combined Model Usually Breaks Down
Tighter integration often increases operational convenience while reducing analytical depth, so organisations have to balance workflow simplicity against control fidelity. The hardest cases are hybrid estates, where cloud apps, legacy systems, contractors, and machine identities all sit under different entitlement models. In those environments, a single platform often cannot keep up with disconnected ownership, delayed sync, or policy rules that differ by system.
Another common edge case is when teams expect governance to be “built in” because the platform can generate reports. Reporting is not the same as control verification. If the platform cannot validate access against authoritative application state, then review results become snapshots of incomplete data. That is especially true for NHIs, where one secret, token, or certificate may grant access across multiple services and may not be tied cleanly to a human-style approval flow. The 2024 ESG report on managing non-human identities is relevant here because it reflects how frequently organisations encounter compromise and governance gaps when lifecycle discipline is weak.
Best practice is evolving toward a separation of concerns: let provisioning handle lifecycle events, and let governance continuously reconcile entitlements, policy, and exceptions. That separation is not overhead for its own sake; it is what makes the control defensible when auditors, incident responders, or platform owners ask for proof.
Risk and Threat Considerations
The material risk in combining provisioning and governance is that it creates a false sense of control while leaving privilege drift, orphaned access, and hidden machine credentials insufficiently visible. That is a governance exposure first, but it also becomes a threat problem when stale or over-privileged access is available for abuse.
Failure mechanism: Provisioning-centric platforms often trust the source directory or workflow state as evidence of legitimacy, yet attackers and internal misuse benefit from the gap between issued access and actual effective access. If governance cannot reconcile entitlements across disconnected systems, excessive access persists, review outcomes become incomplete, and revocation may miss delegated, inherited, or non-human credentials.
Impact: The practical consequence is delayed detection of policy violations, weaker auditability, and a larger blast radius when an account, token, or service identity is compromised. In NHI-heavy estates, that can mean silent persistence through unmanaged secrets or dormant integrations that remain valid long after the original business need has ended.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Provisioning and governance split affects access approval, revocation, and entitlement review. |
| 5 — Account Management | Provisioning platforms handle account lifecycle, but governance must verify account legitimacy and persistence. | |
| Recommendation — Separate joiner-mover-leaver workflows from entitlement review and revoke stale access quickly. Inventory all accounts and remove stale or orphaned access that provisioning alone will miss. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication, and Access Control | The question centers on managing access state and policy across systems. |
| GV.RM — Risk Management Strategy | Combining functions creates governance risk and false confidence in control coverage. | |
| Recommendation — Map issuance, review, and revocation to distinct access-control processes and measure each separately. Define where automation ends and where governance evidence must be independently validated. | ||
| NIST AI RMF | MAP — Map Context and Risk | The question involves mapping access relationships and control boundaries across connected systems. |
| Recommendation — Map actual access relationships before deciding which control layer owns approval or oversight. | ||
Practitioner Guidance
What to prioritise: Treat provisioning fidelity and governance accuracy as separate success criteria. If the platform cannot show effective access across connected systems, do not count it as a governance control no matter how clean the onboarding workflow looks.
Decision rule: If the environment includes SaaS sprawl, cloud entitlements, or machine identities, separate attestation and reconciliation from account issuance. If the access path cannot be validated back to the target system, treat the review result as incomplete rather than approved.
What practitioners underestimate: The main failure is not that the platform “lacks features,” but that teams trust one data model to describe two different realities. That shortcut usually surfaces first in audit exceptions, then in delayed revocation, and finally in incident response when nobody can prove what access actually existed.
Practitioner takeaway: The right design is not one platform doing everything; it is one provisioning plane and one governance plane with explicit reconciliation between them, so that lifecycle automation never substitutes for entitlement truth.
Related resources from NHI Mgmt Group
- What breaks when organisations try to use one identity suite for every governance problem?
- What breaks when organisations try to modernize identity for legacy applications with a manual rewrite approach?
- What breaks when organisations try to build identity governance only from logs?
- How do organisations evaluate whether they need one platform for both data access and identity governance?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
