What should teams do when lifecycle tools cover modern SaaS but not mainframe systems?

Why mainframe coverage is part of lifecycle governance, not a carve-out

When lifecycle tooling stops at SaaS, the problem is not that the mainframe is different, it is that the control plane is incomplete. Joiner, mover, and leaver governance only works when the system of record can create, change, and remove access everywhere the workforce can still reach, including legacy platforms with distinct account models and audit expectations.

Mainframes often remain business-critical, so access changes that are “out of band” become the weak link. If teams rely on separate ticket queues or manual operators for RACF, ACF2, or Top Secret, they introduce delay, inconsistent evidence, and a higher chance that an apparently closed access request still leaves active entitlement behind.

The practical test is simple: if the lifecycle process cannot demonstrate the state of those legacy targets, then it cannot claim full joiner, mover, and leaver closure. That matters as much for recertification and evidence as it does for day-to-day provisioning, because auditors and operators both care whether the control actually spans the full access surface.

What breaks when mainframe updates are handled outside the primary tool

The most common failure mode is a dual control plane. SaaS access changes may flow through automation, while mainframe access depends on manual steps, separate approvals, or delayed batch work. That split creates inconsistent policy enforcement, especially when a user changes role, leaves the organisation, or needs urgent removal after a termination event.

Another failure is entitlement drift. A person can appear clean in the modern IAM console while still retaining access on the host side, which means role changes are only partially effective. The risk is not just stale access, but also weak evidence quality: teams may be unable to prove who approved the change, when it took effect, or whether the target system actually updated.

IAM and IGA Basics is useful here because it frames lifecycle control as a governance problem across entitlement creation, review, and removal, not just a provisioning workflow. For teams that need an operating model for end-to-end lifecycle handling, Joiner-Mover-Leaver (JML) Guide shows why leaver actions must include revocation, not only account disablement in the newest platform.

How teams should extend lifecycle control to RACF, ACF2, and Top Secret

Teams should treat the legacy platform as a first-class provisioning target. That means the lifecycle tool, or an integrated downstream workflow, must be able to provision, recertify, and revoke access on the host with the same ownership, timing, and evidence expectations used for SaaS. If the mainframe still relies on human workarounds, then the exception should be explicit, bounded, and reviewed, not hidden inside a “temporary” process that becomes permanent.

Good design usually has three properties. First, a single authoritative trigger for the lifecycle event. Second, a deterministic mapping from the business role to the mainframe entitlement or group structure. Third, machine-readable evidence that the host-side action completed successfully, not just that a request was submitted. Where those three are missing, teams should not call the control automated, only partially supported.

For organisations that need a model for this kind of operational closure, Ultimate Guide to NHIs is helpful because it treats provisioning, rotation, offboarding, and visibility as one lifecycle problem. Joiner-Mover-Leaver (JML) Guide also reinforces the operational point that revocation must cover the access artifacts people leave behind, which is the same control logic teams need when a legacy target sits outside the modern SaaS path.

Risk and Threat Considerations

When mainframe systems are left out of lifecycle tooling, the exposure is delayed deprovisioning, orphaned access, and weaker evidence of control completion. That can turn a routine mover or leaver event into persistent unauthorized access, especially when the legacy platform holds sensitive business functions or downstream data.

Failure mechanism: The lifecycle event completes in the modern tool, but the host-side account or entitlement remains active because the legacy target depends on manual steps, delayed batch updates, or a separate admin queue.

Impact: Attackers, insiders, or simply former users can retain access longer than intended, and security teams may not notice because the primary governance report shows the request as closed.

Practitioner Guidance

What to verify: Confirm that the lifecycle process can show successful state change on the mainframe itself, not merely that a ticket, request, or middleware event was raised. If the evidence cannot prove the RACF, ACF2, or Top Secret outcome, the workflow is not yet trustworthy for leavers.

Decision rule: If a system still carries workforce access and can influence business operations, put it inside the standard joiner, mover, and leaver control path. Treat any separate manual exception as temporary technical debt with an owner, expiry date, and reconciliation step.

Practitioner takeaway: The goal is not to eliminate legacy platforms, it is to eliminate invisible access paths, because lifecycle governance only works when every active target is revocable, reviewable, and evidenced through one control story.

Related resources from NHI Mgmt Group

• What should security teams look for in alerting tools that touch SaaS and identity systems?
• What should teams do when a SaaS-first access tool does not cover regulated systems?
• What breaks when DLP is limited to on-premises systems and does not cover modern collaboration tools?
• How should security teams assess whether compliance tools are enough when sensitive data moves across SaaS, cloud, and AI systems?