TL;DR: Live Oak Bank’s case study shows how disconnected and hard-to-integrate applications can force manual joiner, mover, leaver, and access review work into regulated environments, even when auditability is non-negotiable, according to Opnova. The core issue is not automation alone but evidentiary completeness: identity governance must produce repeatable actions and audit-grade records across every governed application.
At a glance
What this is: This case study shows how a regulated bank extended identity governance to disconnected and API-limited applications, with the key finding that audit-grade lifecycle execution depends on repeatable actions and complete evidence.
Why it matters: It matters because IAM teams in regulated environments must govern applications that sit outside standard integrations without weakening SOX controls, audit readiness, or lifecycle consistency.
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- Only 5.7% of organisations have full visibility into their service accounts.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
👉 Read Opnova's case study on governing disconnected applications at Live Oak Bank
Context
Disconnected applications create a governance gap when joiner, mover, leaver, and access review workflows must still be executed with the same evidence standard as integrated systems. In regulated banking, the problem is not whether the task can be done manually, but whether it can be done consistently, on cadence, and with audit-ready proof.
For identity governance programmes, this is a lifecycle and evidence problem as much as an automation problem. If an application cannot participate cleanly in the governance layer, teams either absorb ongoing custom integration work or accept manual processes that do not scale with control expectations.
Key questions
Q: How should teams govern disconnected applications that do not expose APIs?
A: Treat them as governed exceptions with a defined workflow, not as informal manual tasks. The control design should preserve approval, execution, and evidence capture in one path so the identity record stays complete enough for audit and access review.
Q: Why do disconnected apps create so much risk for IAM teams?
A: They break the normal identity control loop. When provisioning, certification, and deprovisioning depend on tickets or email, access becomes slower to correct, harder to audit, and easier to overlook. The risk grows when the app is business critical but still outside integrated lifecycle controls.
Q: What are the biggest mistakes teams make with manual access governance?
A: The common mistakes are letting manual handling become permanent, accepting inconsistent evidence quality, and allowing each application to develop its own process. Over time, that fragments governance and makes access reviews harder to trust.
A: Standardise the evidence model first. Automation that produces incomplete or inconsistent records only makes the gap faster, while a clear evidence standard lets teams judge whether the workflow is actually improving control quality.
Technical breakdown
Why audit-grade documentation is part of the control, not a by-product
In regulated identity programmes, documentation is not a post-processing task. A joiner, mover, leaver event or entitlement change must produce records that are traceable end to end, legible to auditors, and reproducible after the fact. If the workflow succeeds but the evidence cannot be reconstructed, the control is incomplete. This is why evidence quality, timing, and consistency are core design requirements for identity governance in SOX-scoped systems, especially where access decisions must survive external review.
Practical implication: validate whether every governed action leaves a complete evidence chain before expanding automation to more applications.
Why custom per-application development becomes a governance liability
When every application requires bespoke integration work, the burden shifts from identity governance to code maintenance. Each custom path creates a separate failure surface for lifecycle changes, access request handling, and access review support. Over time, that fragments control consistency and raises the cost of keeping the programme current. The issue is not only implementation complexity. It is that governance rules stop behaving like a standard and start behaving like a collection of one-off projects.
Practical implication: reduce per-application customisation where possible, because maintenance debt eventually becomes governance drift.
NHI Mgmt Group analysis
Disconnected applications create a governance exception that becomes permanent unless the control model changes. In regulated IAM, manual handling can work for a small portfolio, but it does not remain equivalent to governed lifecycle execution as scale rises. The real failure mode is not lack of effort, but the absence of a repeatable control path that preserves both timing and evidence. Practitioners should treat disconnected apps as a distinct governance class, not as an edge case to absorb indefinitely.
Audit readiness is an access-control requirement, not a reporting add-on. Live Oak Bank’s emphasis on complete, provable actions reflects a core regulated identity principle: if the control cannot be demonstrated on demand, it is not finished. That matters most for SOX-scoped systems, where entitlement changes and access reviews must be reconstructible for internal and external scrutiny. The implication is that evidence generation belongs inside the workflow design.
Custom integration debt weakens governance consistency faster than teams expect. The article shows why per-application platform development is not just an engineering cost. Every bespoke path increases the chance that lifecycle handling, approval logic, or documentation quality will diverge across systems. For IAM leaders, the strategic question is whether the programme can scale control consistency without creating a parallel maintenance function.
NHI lifecycle thinking applies here even when the subject is a human-access workflow. The same governance discipline used for non-human identities shows up in the need for visibility, repeatability, and revocation discipline across application access paths. The lesson is broader than one bank or one vendor: lifecycle control fails when execution moves outside the governed system boundary, regardless of whether the target is human or machine-mediated.
From our research:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, showing how quickly governance breaks down when lifecycle execution is not standardised.
- Use the NHI Lifecycle Management Guide to compare lifecycle discipline across provisioning, rotation, and offboarding.
What this signals
Disconnected application governance is becoming a programme design issue, not just an integration issue. As regulated estates accumulate more exceptions, teams need a distinct operating model for systems that cannot participate natively in standard identity workflows, especially where evidence quality is part of the control.
Evidence-first governance: the practical standard is no longer simply whether access can be changed, but whether each change can be proven after the fact. That shift affects workflow design, auditor expectations, and the amount of manual reconciliation identity teams can sustain.
With only 5.7% of organisations having full visibility into their service accounts, the broader lesson is that visibility and revocation discipline matter across both machine and human-adjacent governance paths, especially when access paths are fragmented.
For practitioners
- Map disconnected applications to a governance exception inventory Identify every SOX-scoped or critical application that cannot participate natively in your identity governance workflows, then classify the reason it is disconnected, API-limited, or custom-integrated. Use that inventory to decide which systems need controlled workflow automation versus manual oversight.
- Require audit-grade evidence for every lifecycle change Define the minimum evidence package for joiner, mover, leaver, and access review actions, including who approved, what changed, when it changed, and how the record can be reconstructed later. Do not expand automation until that evidence is consistently produced.
- Reduce per-application custom development where possible Prefer repeatable workflow patterns over bespoke code for each application, because each custom integration adds maintenance burden and increases the chance of governance drift. Measure the ongoing support cost of each exception against the control value it delivers.
- Separate operational execution from evidentiary reconciliation Make sure the workflow that performs the access change also emits the evidence needed for review, instead of relying on a second manual reconciliation step after the fact. This reduces delay and closes gaps in audit preparation.
Key takeaways
- Disconnected applications create a control gap when lifecycle work must still be provable, repeatable, and audit-ready.
- Manual handling may preserve function for a time, but custom integration debt and weak evidence chains erode governance consistency at scale.
- IAM teams should standardise evidence first, then automate exception paths only where the resulting control can survive audit scrutiny.
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 and CIS Controls v8 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 post centres on governed access changes and review consistency across regulated applications. |
| Recommendation — Map disconnected-app workflows to PR.AC-4 and enforce consistent access permissions across every governed system. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | SOX-scoped entitlement changes must preserve least privilege even when the app is not natively integrated. |
| AU-3 — Content of Audit Records | Audit-grade documentation is a central control requirement in the case study. | |
| Recommendation — Apply AC-6 to limit entitlements in disconnected applications to the minimum needed for each role. Apply AU-3 to ensure each lifecycle event creates complete audit records that can be reviewed later. | ||
| CIS Controls v8 | CIS-5 — Account Management | The case is fundamentally about account lifecycle handling across hard-to-integrate systems. |
| Recommendation — Use CIS Control 5 to standardise account lifecycle handling and eliminate ad hoc manual access changes. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The article is about controlling access consistently across regulated systems and evidence paths. |
| Recommendation — Align disconnected application workflows to A.5.15 so access control stays consistent across all systems. | ||
Key terms
- Disconnected Application: An application that is not integrated with the organisation's central identity and access stack. Access is often managed through shared passwords, manual approval, or local admins, which makes revocation, evidence, and ownership harder to enforce consistently across the application lifecycle.
- Audit-Ready Evidence: Audit-ready evidence is access proof that can be retrieved directly from the control system without manual reconstruction. It should show who approved access, what policy they used, when the decision occurred, and whether any exceptions or compensating controls were applied.
- Governance Exception: A governance exception is a known gap that is allowed to remain outside the normal control process. In identity programmes, unresolved accounts should not be treated as routine exceptions because they can hide risk, distort reviews, and weaken lifecycle controls if they are not tracked to closure.
- Lifecycle Change Log: A lifecycle change log records joiner, mover, leaver, and privilege changes over time for a given identity. It provides the historical trail needed to prove that access was created, modified, or removed according to policy rather than by informal manual action.
What's in the full article
Opnova's full case study covers the operational detail this post intentionally leaves for the source:
- How Live Oak Bank evaluated disconnected and API-limited applications against its governance requirements
- The specific workflow patterns used to reduce manual effort while preserving evidence quality
- The bank's validation approach for repeatability before moving into live operations
- The operational shift that freed IAM teams to focus on higher-value governance work
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on September 22, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
