What should teams do when IGA coverage does not extend to mainframe or bespoke systems?

Why This Matters for Security Teams

When identity governance and administration does not reach a mainframe or bespoke platform, the risk is not just inconvenience. It is a blind spot in joiner, mover, and leaver control, which means privileged access can outlive the business need that justified it. NHI Management Group consistently warns that uncovered systems should be treated as exceptions, not as acceptable long-term gaps, because exception handling becomes the real control surface. See also the DeepSeek breach for how exposed credentials and weak oversight can cascade into broader compromise.

Security teams often assume the hardest part is technical integration, but the bigger issue is governance: who owns the account, how it is reviewed, and what evidence proves removal when access should end. Without that discipline, mainframe IDs, service accounts, and bespoke application users can persist for years outside normal review cycles. The NIST Cybersecurity Framework 2.0 reinforces that asset and identity control must be measurable even when tooling is uneven. In practice, many security teams only discover these orphaned paths after an audit finding or a deprovisioning failure has already occurred, rather than through intentional lifecycle management.

How It Works in Practice

The practical answer is to bridge the coverage gap with compensating controls that behave like an interim control plane. Start by cataloguing every system that sits outside native IGA coverage, then assign a named business owner and a technical custodian for each one. From there, define a manual or semi-automated review cadence, preferably tied to access certification, account recertification, and termination workflows. The goal is to make the exception visible, reviewable, and revocable.

For high-risk systems, teams should require evidence of deprovisioning rather than relying on verbal confirmation. That usually means pairing ticket closure with screenshots, export logs, batch reports, or change records that show the account was removed, disabled, or rotated. Where possible, use directory synchronization, PAM, or workflow hooks to reduce manual steps, but do not wait for a perfect connector before enforcing review. This is especially important for legacy estates, where current guidance suggests that compensating controls are acceptable only when they are explicit, time-bound, and monitored.

• Map uncovered systems to a risk tier and assign an accountable owner.
• Require periodic attestation for every privileged and non-privileged account.
• Capture deprovisioning evidence and retain it with the access record.
• Escalate exceptions that persist beyond an agreed remediation window.

For broader secrets and credential exposure patterns, NHI Management Group’s research on the State of Secrets in AppSec shows why fragmented control often outlives initial remediation efforts. These controls tend to break down when a bespoke platform has no reliable ownership metadata because review tasks become ambiguous and unenforceable.

Common Variations and Edge Cases

Tighter exception governance often increases operational overhead, so organisations must balance control strength against the cost of manual review. That tradeoff is unavoidable in environments where mainframes, vendor-managed platforms, or custom code bases cannot accept a modern connector. In those cases, current guidance suggests prioritising the highest-risk identities first: administrator accounts, shared IDs, service principals, and any account that can alter data or permissions.

There is no universal standard for how to attest every legacy account, so best practice is evolving. Some teams use quarterly certification for privileged access and semiannual reviews for lower-risk accounts, while others align with system criticality or audit requirements. The key is consistency. If an exception is allowed, it must have an owner, a review date, and a documented fallback when evidence is missing. For organisations dealing with credential leakage concerns, the Schneider Electric credentials breach is a useful reminder that fragmented oversight can become a security event, not just a process issue.

The approach breaks down when no one can prove who receives access, who approves it, or who removes it, because the exception then becomes a permanent shadow identity problem.

Related resources from NHI Mgmt Group

• What do teams get wrong about similarity scores and prompt rules in RAG systems?
• How should teams govern identity data when AI systems consume it directly?
• How should payment teams balance compliance and fraud controls in APAC P2P systems?
• How should security teams govern Slack access like other high-value identity systems?