Should organisations rely on Git alone for identity recovery?

Why Git Alone Is Not a Recovery Strategy

Git is excellent for governance, review, and version history, but recovery depends on what is actually available to restore. Identity systems fail in ways that extend beyond committed files, including live privilege assignments, tokens, sessions, directory objects, linked integrations, and configuration drift. A Git repository can tell you what was intended, not necessarily what is presently trusted or operational.

That distinction matters because organisations often discover the gap only after an outage, compromise, or bad automation change. NHIMG’s Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a strong reminder that recovery must account for live identity state, not just source-controlled intent.

In practice, teams usually learn this when a restore succeeds technically but the recovered identity still cannot authenticate, authorize, or reach the systems it once depended on.

How Recovery Actually Works in Practice

A workable recovery design separates governance from restoration. Git should hold approved configuration, policy, and intended relationships, while an immutable backup or recovery store preserves the runtime artefacts needed to bring identity services back into a usable state. That usually includes directory state, federation settings, privileged assignments, certificate material, and evidence of what was active at a point in time.

For identity recovery, the hard part is not versioning the file, it is preserving the operational context around the file. A repository can show that access was granted, but not whether a downstream application cached trust, whether a token remains valid, or whether a manual hotfix changed an object outside the commit path. If you restore from Git alone, you may reintroduce stale privileges or miss objects that were never committed. NHIMG’s Top 10 NHI Issues is useful here because it reflects the recurring problems teams face around visibility, rotation, and lifecycle control.

• Use Git as the source of approved change and audit evidence.
• Keep a separate immutable recovery copy for stateful identity components and dependencies.
• Test restores against the full trust chain, not just the repository contents.
• Record which objects are generated at runtime, because those often need separate protection.

Teams should also confirm that recovery procedures cover credential rotation, revocation, and reissuance after restore, because a clean rollback of code does not automatically produce a clean rollback of trust. These controls tend to break down when identity is distributed across cloud consoles, directory services, and automation pipelines because no single restore source captures the full live state.

Common Variations and Edge Cases

Tighter Git discipline often increases operational overhead, so organisations have to balance auditability against the need for fast restoration. Some environments are simple enough that Git plus a backup of the identity platform is sufficient, while others require point-in-time recovery, object-level export, or separate vault-backed secret recovery because live relationships matter more than configuration history.

There is no universal standard for this yet, but current guidance suggests treating Git as one control in a broader recovery architecture, not as the recovery architecture itself. That becomes especially important where identities are created and changed by automation, because the commit history may be accurate while the runtime object graph is not. NHIMG’s 52 NHI Breaches Analysis helps illustrate why lifecycle failures and weak visibility so often turn small control gaps into larger incidents.

When organisations rely on Git alone, the biggest edge case is not a missing file, it is a missing trust dependency, for example a certificate chain, external integration, or federated relationship that was never fully captured in the repository.

Risk and Threat Considerations

Relying on Git alone creates recovery risk, privilege risk, and integrity risk. The repository may be correct as a change record while still being incomplete as a restoration source, which leaves organisations exposed to failed recovery, stale access, or silently broken trust relationships.

Failure mechanism: Identity data often changes outside the normal commit path through consoles, APIs, scheduled jobs, or emergency admin actions. If recovery depends only on Git, those live changes are lost, while orphaned permissions, expired credentials, or detached trust links may persist unnoticed.

Impact: Recovery can restore the wrong state, fail to restore essential access, or reintroduce access that should have been revoked. That can extend outage duration, weaken control assurance, and create a path for misuse if old privileges or tokens remain in circulation.

Practitioner Guidance

What to prioritise: Protect the restore path before you optimise the commit path. For identity systems, the first question is whether you can rebuild a trusted working state, not whether every change was committed cleanly.

What to verify: Test restores against live dependencies, including credentials, federation, directory objects, and any runtime-generated state. A restore is only successful if the recovered identity can authenticate, authorize, and operate as expected.

Practitioner takeaway: Use Git to prove what should exist, but keep a separate recovery mechanism to restore what must actually function.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on human judgment alone to approve identity resets?
• What breaks when organisations rely on product security alone and ignore the identity layer in cloud espionage defence?
• What breaks when organisations rely on document authenticity alone for identity verification?
• What breaks when organisations rely on visibility alone instead of recovery for critical configuration changes?