How should security teams implement reconciliation in identity governance programs with connected applications and manual admin changes?

Why This Matters for Security Teams

Reconciliation is where identity governance becomes operational proof. In connected applications, the IGA record is only useful if it matches the state in downstream systems that admins, automation, and integrations can change without waiting for governance workflows. Without continuous reconciliation, access reviews can certify stale entitlements, orphaned accounts can survive deprovisioning, and manual fixes can quietly bypass approvals.

This matters even more in environments with service accounts, delegated admin roles, or SaaS apps with weak event logging. NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which is a strong signal that many reconciliation gaps are not seen until after drift has accumulated. The operational lesson is simple: if access state is not continuously compared across systems, governance reports become documentation of intent, not evidence of control. That is why current guidance aligns reconciliation with the control objectives in the NIST Cybersecurity Framework 2.0 and the control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls.

In practice, many security teams discover reconciliation failures only after an audit exception, an access incident, or a manual admin change that was never reflected back into the IGA system.

How It Works in Practice

Effective reconciliation compares the authoritative entitlement model in the IGA platform with the actual state in each connected application, directory, or infrastructure target. The point is not just to find mismatches, but to classify them so the right workflow can respond. A changed group membership, a direct entitlement grant, or a restored account after an outage may all look like drift, but they do not all carry the same risk.

A practical program usually combines scheduled discovery with event-driven checks. Scheduled jobs catch systems that do not emit reliable change events. Event-driven checks catch manual admin changes sooner, especially when a privileged operator creates an account, adds roles, or reactivates access outside the standard request flow. For high-risk systems, reconciliation should also confirm whether accounts are still tied to an approved owner and whether credentials, keys, or tokens have been rotated after a change.

• Compare desired state to actual state by application, not just by identity record.
• Flag orphaned accounts, direct assignments, and entitlements missing a valid request or approval.
• Route exceptions into attestation, remediation, or just-in-time removal workflows.
• Preserve evidence of who changed what, when, and why for audit and root-cause analysis.

NHIMG’s Lifecycle Processes for Managing NHIs emphasises that lifecycle control only works when revocation, rotation, and offboarding are verified in the target system, not merely requested in the governance tool. For implementation, teams often map reconciliation requirements to NIST SP 800-53 Rev 5 Security and Privacy Controls so exceptions can be tracked as control failures rather than informal tickets. These controls tend to break down when applications allow hidden local administration because the IGA platform cannot reliably observe direct changes.

Common Variations and Edge Cases

Tighter reconciliation often increases operational overhead, requiring organisations to balance stronger assurance against application complexity and admin friction. That tradeoff is especially visible in legacy systems, SaaS platforms with limited APIs, and environments where local administrators are expected to make urgent changes during incidents.

Best practice is evolving for these cases. Where full automation is not possible, current guidance suggests defining a reconciliation tiering model: critical systems get frequent checks and stricter exception handling, while lower-risk systems can rely on longer intervals and sampled review. For manual admin changes, the control objective should be immediate traceability, not necessarily immediate blockage, provided the change is reviewed quickly and either normalised into the IGA record or removed.

Third-party and federated applications create another edge case. A direct role assignment inside a vendor console may never pass through internal approval, so reconciliation must look for drift at the provider boundary as well as inside the enterprise directory. NHIMG’s Top 10 NHI Issues is a useful reminder that unmanaged identities and stale entitlements often persist longest where ownership is unclear. In environments with brittle connectors, security teams may need compensating controls such as admin change logs, periodic exports, and targeted attestations to avoid blind spots. There is no universal standard for this yet, but the operational goal remains the same: make every exception visible, owned, and time-bound.

Related resources from NHI Mgmt Group

• How should security teams reduce the backlog of applications without native connectors in identity governance programs?
• How should security teams bring nonstandard applications under identity governance without creating more manual work?
• How should security teams use IAST and RASP in NHI governance?
• How should security teams implement identity governance in SaaS-heavy environments?