TL;DR: Banks can run mature IGA programmes and still fail completeness audits when connector coverage stops at the edge of mainframes, legacy stores and acquired systems, according to Hydden. The real problem is not certification volume but proving the account list is complete, the revocation executed, and the evidence cannot be altered after the fact.
At a glance
What this is: This analysis argues that mature bank IGA programmes still break on completeness because connector-based governance cannot reliably cover every account across legacy and acquired estates.
Why it matters: It matters because IAM, IGA, PAM and audit teams need evidence that the inventory is complete, the change history is durable, and revocations actually reached the source system.
👉 Read Hydden's analysis of why bank IGA programmes still fail completeness audits
Context
Banks often treat identity governance maturity as proof that completeness is solved, but certification coverage is not the same thing as estate coverage. Once the governance platform only knows what its connectors can see, the unanswered question becomes which accounts, systems and access paths were never brought into scope in the first place.
That gap matters most in banks because the hard-to-connect systems are usually the ones that carry the highest risk: mainframes, legacy Unix estates, SQL-backed identity stores, payment platforms and acquired environments. In a regulated IAM programme, the issue is not whether reviews happened, but whether the record of access is complete, attributable and durable enough to satisfy audit and supervisory scrutiny.
Key questions
Q: What breaks when an IGA platform has no discovery layer for unconnected applications?
A: Without discovery, governance only covers the apps already in the system of record. That leaves shadow IT, team-purchased tools, and unconnected applications outside provisioning, certification, and remediation workflows. The result is incomplete visibility, weaker role mining, and a false sense of control because the most relevant risks often sit in the apps the platform never learns about.
Q: Why do regulators care about revocation confirmation instead of just approval records?
A: Because an approval shows intent, not execution. Regulators want evidence that the access change reached the source system and actually took effect, especially where a ticket is closed but the entitlement may still exist in a mainframe, legacy directory or application table.
Q: How should banks prove their access reviews are actually working?
A: They should test whether the review process produces a complete account list, durable change history and source-system confirmation for revocations across the full audit period. If any of those three pieces is missing, the review is only proving campaign activity, not control effectiveness.
Q: How can identity teams govern legacy accounts and AI agent accounts under the same model?
A: Use one inventory, one ownership model and one evidence record for both. The difference is that AI agent credentials may be short-lived and harder to observe, so the governance process must rely on authoritative system events rather than periodic snapshots alone.
Technical breakdown
Why connector-based IGA leaves blind spots in legacy estates
Most IGA platforms certify what they can connect to, not what the enterprise actually runs. That works for modern directories and applications with clean identity APIs, but it fails where accounts live inside application tables, security managers, or older systems that never exposed identity events cleanly. In those environments, the platform can produce a correct report for a partial estate while still missing the accounts that matter most. The architectural limitation is not a bug in certification logic. It is a boundary problem created by connector coverage, inconsistent logging, and systems that sit outside the governance platform's field of view.
Practical implication: inventory the systems outside connector coverage first, then treat them as governed scope rather than edge cases.
Why certification snapshots do not prove audit completeness
A certification campaign captures access state at one point in time. Auditors and examiners, however, are asking a different question: what changed between campaigns, who approved it, and did the revocation actually execute in the source system. A snapshot can show that access existed on review day, but it cannot prove a temporary privilege was granted and removed in the audit window unless the lifecycle events are retained as durable records. That is why reconciliation, provenance and execution evidence matter more than the approval record itself.
Practical implication: preserve change events and revocation confirmation separately from the campaign record so auditors can trace the full access lifecycle.
Why the account record must live outside the systems it describes
When the governance platform stores the evidence it is meant to prove, the record becomes part of the control surface. If administrators can change configuration, modify records, or adjust visibility, the assurance story weakens because the same users can influence both the access decision and the proof of that decision. Banks need a system of record that is append-only and independent of the systems under review. That is what gives identity governance weight in audit and supervisory contexts: not just knowing who had access, but proving the evidence itself was outside the reach of ordinary administrative change.
Practical implication: move evidence retention to an append-only record that cannot be edited by the people whose access it documents.
NHI Mgmt Group analysis
Connector completeness is the real control boundary in bank IGA. A mature certification programme does not equal full estate visibility when the platform only covers connected applications. In banking, the systems that escape connector coverage are often the ones regulators care about most, which means the governance boundary is set by architecture rather than policy. Practitioners should treat coverage gaps as a control failure, not as a reporting inconvenience.
Audit completeness is now a lifecycle problem, not a campaign problem. Review approvals alone cannot satisfy examiners asking for who had access, when it changed, and whether revocation reached the source system. The gap is the absence of durable event history across the full access lifecycle, especially for temporary privilege and hard-to-monitor systems. Teams need to think in terms of attributable access history, not certification cadence.
Append-only evidence is the named concept this market keeps converging on. When the record of access can be altered by the same administrators whose actions it documents, assurance collapses into self-reporting. This is why identity governance, PAM and audit evidence now need a system of record outside the governed estate. The practitioner conclusion is simple: if the evidence can be edited, the control has not really been proven.
Banking regulators are implicitly testing whether identity governance can span human IAM, NHI-style service accounts, and legacy application accounts under one evidence model. The article shows the same completeness issue appearing across privileged access, vendor staff, application accounts and emerging AI tooling. That convergence means the identity programme has to reconcile multiple actor types without splitting assurance into separate silos.
AI agent governance inherits the same completeness problem, only faster. When an agent authenticates through a short-lived service principal or workload identity, schedule-based polling may never observe the credential at all. The same architectural weakness that hides legacy accounts can also hide ephemeral agent access, so banks should stop treating agent governance as a separate domain from NHI completeness.
From our research:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- A separate finding in the same report shows that only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which reinforces how quickly incomplete identity visibility becomes a governance problem.
- That visibility gap is why banks should read Ultimate Guide to NHIs - Key Challenges and Risks alongside NHI Lifecycle Management Guide when designing inventory and evidence controls.
What this signals
Banks should expect identity programmes to be judged less by certification volume and more by whether the governance record can reconcile to the real estate. The operational signal is simple: if the platform cannot enumerate every account path, the audit story will fail at the point of completeness rather than at the point of review.
Append-only identity evidence: this is becoming the practical differentiator between a workflow tool and a system of record. Once administrators can alter the proof of access decisions, the programme has to move evidence retention outside the systems under review and into a store that supports audit-grade provenance.
The same completeness model will increasingly be applied to service principals, workloads and AI agents, because short-lived credentials can evade snapshot-based review. Teams that already struggle with legacy estates should assume their agent governance will inherit the same visibility problem unless access events are captured continuously.
For practitioners
- Map every unconnected system in scope Identify mainframes, legacy Unix estates, SQL-backed identity stores, acquired platforms and any system that does not feed the governance connector catalog. Use that list to define the true audit boundary, not the platform's current connector boundary.
- Separate approval records from execution evidence Retain reviewer, timestamp and rationale alongside a source-system confirmation that the revocation or disablement actually executed. A closed ticket is not sufficient evidence when the examiner wants proof in the authoritative system.
- Create an append-only identity system of record Store identity change events in a record that cannot be edited or deleted by the administrators whose actions it contains. If the platform can modify its own proof, the assurance model is still self-referential.
- Reconcile privileged inventories against HR and source systems Generate account lists from the systems themselves, then reconcile them with HR and access-review outputs so missing accounts, orphaned entitlements and ownerless privileged access are visible before audit sampling begins.
- Treat AI tooling as governed account inventory Apply the same ownership and evidence model to AI agents, service principals and workload identities that banks already expect for privileged human access, because short-lived credentials can disappear before a periodic review sees them.
Key takeaways
- Mature IGA does not guarantee audit completeness when connector coverage stops short of the real estate.
- The key evidence gap is between access approval and source-system execution, not between policy and intention.
- Banks need append-only identity records that prove account history outside the systems being certified.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the technical controls, while ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorisations | The article centres on proving access scope across the estate. |
| Recommendation — Map access inventories to PR.AC-4 and verify completeness across every in-scope system. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Incomplete inventories undermine least-privilege validation in regulated estates. |
| Recommendation — Apply AC-6 to validate privilege scope against the authoritative account inventory. | ||
| CIS Controls v8 | CIS-5 — Account Management | The post is fundamentally about account inventory and review coverage. |
| Recommendation — Use CIS Control 5 to reconcile account ownership, review status and orphaned access. | ||
| ISO/IEC 27001:2022 | A.8.2 — Privileged Access Rights | Banks need privileged access evidence that withstands audit and supervisory review. |
| Recommendation — Apply A.8.2 to govern privileged access rights with durable, reviewable evidence. | ||
| NIST Zero Trust (SP 800-207) | Principle of least privilege — Principle of least privilege | The completeness problem affects trust decisions across connected and unconnected systems. |
| Recommendation — Extend zero-trust access decisions to unconnected systems and verify each entitlement source. | ||
Key terms
- Identity System of Record: The authoritative source that shows what access an identity actually has. For human, machine, or agent identities, the system of record is the place where entitlement state should be reconciled after request fulfilment. Without it, ticket approvals can diverge from real access.
- Connector coverage: Connector coverage is the extent to which an identity platform can integrate with the systems where real access decisions exist. It matters because governance controls only work when the platform can see entitlements, roles, and conflicts in the applications that actually hold risk.
- Audit Completeness: The degree to which a control plane records enough detail to reconstruct what happened, who did it, and what data or action was involved. For MCP, completeness means tool calls, prompts, responses, and identity context are available for investigation and compliance.
- Append-Only Evidence: Evidence that can be added to but not altered or deleted after the fact. In identity governance, this gives access reviews and revocation proof durability, because the people whose actions are being recorded cannot rewrite the record to improve their own audit outcome.
What's in the full article
Hydden's full blog post covers the operational detail this post intentionally leaves for the source:
- How the identity system of record reconstructs account history from systems that never wrote usable logs
- How source-system revocation confirmation differs from ticket closure in audit evidence
- How the record links accounts to people or workloads across mainframes, SQL-backed stores and acquired environments
- How the bank-facing evidence model supports SOX, NYDFS, DORA and PCI review requests in different formats
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on September 11, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org