Who is accountable when identity data is not synchronised?

Why This Matters for Security Teams

Identity synchronisation is not just a directory hygiene task. It is the mechanism that determines whether access decisions, audits, and revocation actions all point to the same person, service account, or NHI record. When identity data diverges across systems, authentication may still succeed while authorisation, logging, and incident response become unreliable. That creates a governance gap, not merely an operational inconvenience.

This matters because control ownership is often split between IAM, platform, and application teams, yet the failure shows up wherever a stale or mismatched identity is consumed. NIST’s Cybersecurity Framework 2.0 treats identity management as part of broader governance and access control, while NHIMG research shows why the issue is persistent: only 5.7% of organisations have full visibility into their service accounts, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. The same pattern appears across Ultimate Guide to NHIs and 52 NHI Breaches Analysis: once identity truth fragments, security teams lose a reliable basis for least privilege and offboarding.

In practice, many security teams encounter the accountability problem only after a stale account, duplicate identity, or failed deprovisioning event has already created exposure.

How It Works in Practice

Accountability should sit with the identity governance owner because synchronisation is a control outcome that depends on policy, process, and system integration. That owner may not operate every directory or application, but they must define the authoritative source, reconciliation rules, and exception handling. Without that, teams can neither prove who has access nor revoke it with confidence.

Operationally, the control model usually works like this: one authoritative identity source feeds downstream directories, SaaS platforms, and privileged access systems; reconciliation jobs compare records; discrepancies trigger remediation; and deprovisioning is verified across all connected systems. For NHIs, the same model extends to service accounts, API keys, tokens, and certificates, which must be tied to workload ownership and lifecycle events. NHIMG’s Ultimate Guide to NHIs — Key Research and Survey Results highlights why this matters: 71% of NHIs are not rotated within recommended time frames, and 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

• Define the system of record for each identity type, including human, service, and application identities.
• Set synchronisation SLAs for create, modify, disable, and delete events.
• Require reconciliation reports that identify orphaned, duplicated, and stale records.
• Escalate unresolved mismatches to the identity governance function, not to application owners alone.

For practitioners, the key question is not whether a sync failed, but whether the organisation can still trust access state after the failure. These controls tend to break down in federated environments with multiple HR feeds, shadow directories, and unmanaged API credentials because no single team can prove which record is authoritative.

Common Variations and Edge Cases

Tighter synchronisation control often increases integration overhead, requiring organisations to balance consistency against application autonomy and change speed. That tradeoff is real, especially where legacy systems, mergers, or partner-owned directories cannot be standardised quickly.

Best practice is evolving for edge cases such as contractor identities, temporary admin access, and NHIs embedded in CI/CD pipelines. Current guidance suggests that ownership still remains with identity governance, but implementation may be shared across IAM, PAM, and platform teams. If a system cannot support real-time sync, the organisation should at least enforce compensating controls such as short-lived access, periodic attestation, and explicit expiry for privileged identities. The problem is especially acute for NHIs because service accounts often lack a natural human manager, which makes ownership ambiguous unless workload ownership is documented.

Where consensus is weakest is in multi-directory environments with conflicting attributes. In those cases, the safest approach is to declare a single authoritative source for identity attributes that affect access, then treat every other copy as derived data. That aligns with the governance emphasis in Top 10 NHI Issues and the broader control expectations in NIST CSF 2.0. When organisations avoid assigning a clear owner, synchronisation defects linger until an audit, a breach, or a failed offboarding event forces the issue.

Related resources from NHI Mgmt Group

• Who is accountable when browser-based identity risk causes a data leak?
• Why is it important to integrate identity and data governance?
• How do teams know whether incident data is improving identity governance?
• Who is accountable when automated Jamf actions are triggered from identity events?