Modernizing Mainframe Security: Federating RACF Authentication Into Enterprise IAM
Proactive Security for the AI Era
NodeZero continuously and autonomously pentests infrastructure, identity, cloud, and now web applications, chaining weaknesses across every domain the way real attackers do. Every finding ships with replayable proof showing exploitable business impact, not theoretical risk.
IBM Z shops are getting the same zero-trust and MFA mandates as every other part of the enterprise, and the honest answer for most of them is that RACF, ACF2, and Top Secret were never actually the blocker. RACF has supported 9 to 100 character passphrases and mixed-case, special-character passwords for roughly two decades, and IBM added native multi-factor authentication to z/OS back in 2016. The real gap is organizational: RACF's own MFA capability lives inside the mainframe's own identity silo, disconnected from the enterprise IdP that already handles conditional access, risk scoring, and step-up authentication for everything else. IAM architects don't need to convince anyone that mainframe authentication can be modernized. They need a way to bring RACF, ACF2, or Top Secret logon under the same IdP-driven authentication flow as the rest of the enterprise, without touching the dataset-level and resource-level authorization decisions those security managers still make better than any generic IdP can. This guide walks through that pattern: the problem it solves, what has to be true before you start, a numbered procedure for standing up the federation, how to validate it actually works, where it fails, and the security tradeoffs of putting a gateway in front of a 50-year-old authentication path.
The Problem: Zero-Trust Mandates Hitting an Authentication Silo
Most zero-trust and MFA initiatives are driven by a security or compliance mandate that assumes every authentication event in the enterprise flows through a central identity provider, gets scored for risk, and can be stepped up or blocked based on policy. Mainframe logon usually doesn't participate in that flow at all. A TSO or CICS user typically authenticates directly against RACF, ACF2, or Top Secret with a userid and password (or, at MFA-enabled shops, a password plus a second factor validated entirely inside the mainframe's own MFA stack), completely outside the enterprise IdP's visibility. That produces two concrete problems for an IAM architect. First, the mainframe becomes a documented exception in every zero-trust attestation, audit, or insurance questionnaire, because its authentication events aren't visible to the same conditional access and risk engine covering the rest of the estate. Second, and often underestimated, RACF, ACF2, and Top Secret still make dataset-level and resource-level authorization decisions (who can read, update, or allocate a specific dataset, execute a specific transaction, or use a specific program) that a generic IdP has no model for and cannot replicate. Ripping out the native security manager to solve the authentication gap would mean losing decades of granular resource authorization that nothing in a standard IdP replaces. The practitioner pattern that actually ships in 2026 doesn't try to replace RACF, ACF2, or Top Secret. It federates the authentication step (proving who the user is) through the enterprise IdP over SAML or OAuth, then maps that federated identity to the existing mainframe userid so the security manager's own authorization engine keeps making every downstream access decision exactly as it does today.
Prerequisites Before You Touch Anything in Production
This is not a project you start by editing RACF database entries. Confirm the following before any pilot work begins.
A current inventory of userids, groups, and how they map to real people or services
You cannot build an identity mapping table without knowing which mainframe userids belong to interactive human users versus started tasks, batch jobs, and service accounts. Started tasks and batch jobs generally cannot participate in interactive federation at all, since there is no human present to complete an IdP challenge, so they need to be explicitly scoped out of the federation project rather than discovered as an exception mid-rollout.
A gateway or proxy layer capable of terminating SAML 2.0 or OAuth 2.0/OIDC in front of the mainframe access path
This is the component that actually talks to the enterprise IdP. It can be a z/OS-resident capability such as z/OS Connect, a general-purpose API gateway or reverse proxy already in the enterprise's identity stack, or a purpose-built mainframe identity bridge product. Whichever you choose, it needs to sit in front of every access path you intend to federate (TSO/ISPF, CICS transactions, z/OS Connect APIs) since a federation layer that only covers one access path leaves the others still authenticating natively.
Confirmation that your security manager supports (or can be bridged to) a distributed identity mapping mechanism
RACF has a native mechanism for this: Distributed Identity Filters, configured through the RACMAP command, which associate an external identity (an X.509 certificate Subject DN, a Kerberos principal, or another distributed identity string) with a specific RACF userid without ever exchanging the mainframe password. ACF2 and Top Secret do not expose an identical command set, so for those two, the mapping table of record more often lives in the gateway or bridge product itself rather than in the security manager, which changes where you audit and control that mapping but does not change the underlying pattern.
PassTicket (or equivalent one-time credential) support enabled for the target applications
RACF's Secured Signon (SSIGNON) class generates PassTickets: short-lived, single-use, cryptographically derived credentials that let a front-end component authenticate a user to RACF without ever holding or transmitting that user's actual password. This is the mechanism that lets the gateway complete mainframe logon on the user's behalf after the IdP has already authenticated them.
Executive and audit sign-off on which population pilots first
Because this changes how privileged interactive access to production mainframe resources is authenticated, treat the pilot scope, rollback plan, and fallback authentication path as something audit and change management sign off on before the first userid is migrated, not after.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Procedure: Federating Authentication Without Touching Authorization
The steps below assume RACF as the primary example, since it has the most mature native tooling for this pattern; the ACF2 and Top Secret variants are noted where the mechanism differs.
Step 1: Scope the population and access paths for the pilot
Pick a narrow group of interactive users on a single access path (TSO/ISPF is usually the simplest starting point) rather than attempting CICS, batch, and TSO simultaneously. Exclude started tasks and service accounts entirely from this phase.
Step 2: Configure the enterprise IdP to recognize the mainframe access path as a relying party
Register the gateway or proxy as a SAML service provider or OAuth/OIDC relying party in the enterprise IdP, and apply the same conditional access and MFA policy to it that already governs other sensitive applications, so mainframe logon inherits the IdP's existing risk-based step-up rather than getting a bespoke policy.
Step 3: Build the identity mapping table
For RACF, use RACMAP to create a Distributed Identity Filter that maps the federated identity's registry name and identity string to the correct RACF userid. For ACF2 or Top Secret, configure the equivalent mapping inside the gateway or bridge product, and restrict write access to that mapping table to the same small group that would normally hold RACF SPECIAL or equivalent authority, since a wrong entry here grants the wrong userid's authorization to the wrong person.
Step 4: Enable PassTicket generation for the mapped userids
Activate the SSIGNON class (or the equivalent secured-signon mechanism for ACF2/Top Secret bridge products) for the applications the pilot group needs, so the gateway completes mainframe logon with a one-time PassTicket instead of a stored or transmitted password.
Step 5: Route pilot users through the federated path and disable their native password logon for that access path only
Once a pilot user's SAML or OAuth flow through the gateway is confirmed working end to end, disable direct native password logon for that specific access path so you're validating the real production flow rather than a parallel path nobody actually uses.
Step 6: Leave dataset, resource, and transaction authorization completely untouched
Do not modify RACF, ACF2, or Top Secret profiles, groups, or access lists as part of this project. Authorization decisions (RACROUTE REQUEST=AUTH calls and their ACF2/Top Secret equivalents) should keep evaluating against the exact same userid and the exact same profiles as before; federation only changes how that userid got authenticated. This is also where it's worth revisiting whether existing entitlements reflect [least-privilege access](/blog/iam-least-privilege-implementation), since federation is a natural checkpoint for that review, not a reason to skip it.
Step 7: Expand access-path coverage and user population incrementally
Add CICS and z/OS Connect API access paths, then widen the user population, one wave at a time, using the same pattern: confirm the federated flow works, then disable the native password path for that specific group and access path.
Step 8: Wire SMF audit records into the enterprise SIEM alongside IdP authentication logs
RACF, ACF2, and Top Secret all generate SMF audit records for authentication and access events. Feed those into the same SIEM pipeline as the IdP's authentication logs so an investigation can correlate an IdP-side authentication event with the downstream mainframe userid it mapped to, rather than treating the two as separate audit trails.
Validation: Confirming Federation Actually Works Before You Trust It
A federated logon that appears to succeed is not the same as one that's enforcing the right identity and the right MFA policy. Validate each of the following before declaring a wave complete.
Confirm the SMF record shows the correct mapped userid, not a generic or shared identity
Pull the SMF type 80/81/83 records (or ACF2/Top Secret equivalents) for a pilot user's session and confirm the recorded userid matches the specific individual who authenticated, not a shared service identity the gateway defaulted to on a mapping miss.
Verify a user with no valid mapping entry is rejected, not silently granted a default identity
Deliberately test with an identity that has no corresponding RACMAP (or bridge) entry and confirm the gateway denies access outright rather than falling back to a default or shared userid, which would be a silent privilege escalation path.
Confirm dataset and transaction authorization decisions are unchanged
Run the pilot user through a known set of authorized and unauthorized dataset or transaction access attempts and confirm the results match what they were before federation, proving that authentication changed without authorization silently changing alongside it.
Test PassTicket expiry and replay rejection
Confirm a captured PassTicket cannot be reused after its validity window closes or after a single use, since the entire point of the mechanism is eliminating a durable, replayable credential from the wire.
Confirm the IdP's MFA and conditional access policy actually applies to the mainframe relying party
Trigger the conditions that would normally force step-up MFA at the IdP (a new device, an anomalous location) and confirm the mainframe access path enforces the same challenge, rather than treating the mainframe relying party as exempt from policies applied everywhere else.
Failure Cases: Where This Breaks in Practice
These are the failure modes that show up in real rollouts, not theoretical edge cases.
The identity mapping table drifts out of sync with the IdP directory
When a user is deprovisioned, renamed, or moved in the enterprise directory but the corresponding RACMAP or bridge mapping entry isn't updated, you end up with either an orphaned mapping that should have been removed, or a departed user's federated identity still resolving to an active mainframe userid.
The gateway becomes a single point of failure for all mainframe access
Once native password logon is disabled for a migrated access path, an outage in the gateway or the IdP itself locks out every user on that path, including the operations staff who would normally respond to the outage. Keep a documented, tightly controlled break-glass path for this scenario, and treat it as a genuine operational dependency, not an edge case.
Clock skew breaks PassTicket validation
PassTickets are time-bound and derived using a shared secret and a time value; meaningful clock drift between the gateway and the mainframe LPAR can cause valid logon attempts to fail validation, which looks like an authentication bug but is actually a time synchronization problem.
ACF2 and Top Secret bridges lack the native mapping RACF has, pushing more logic into third-party code
Because ACF2 and Top Secret don't have a direct equivalent to RACF's RACMAP-based Distributed Identity Filters, shops running those security managers usually end up depending more heavily on whatever mapping and PassTicket-equivalent logic the bridge or gateway vendor has built, which means the vendor's own implementation quality becomes a bigger part of your risk surface.
Batch jobs and started tasks get scoped into a project meant for interactive users
Attempting to force non-interactive workloads through an interactive federation flow (or worse, granting them a permanent bypass with weaker controls than before) is a common scope-creep failure. Batch and started-task credentials need their own hardening track, not a workaround inside the interactive federation project.
Security Tradeoffs: What You're Actually Signing Up For
Federating mainframe authentication is a net security improvement for most enterprises, but it is a tradeoff, not a free upgrade, and an IAM architect should be able to state the tradeoff plainly rather than presenting it as risk-free.
You are concentrating trust in the gateway
Every identity that authenticates through the gateway is now trusted by the mainframe based on the gateway's assertion. A compromise of the gateway itself, or of the mapping table it relies on, has a larger blast radius than a compromise of any single native mainframe credential, so the gateway needs security controls (network segmentation, mutual TLS, restricted administrative access) proportional to that trust, and its privileged administration should be treated with the same rigor as any [privileged access management](/blog/how-to-implement-privileged-access-management-cyberark-beyond-trust) target, not as ordinary infrastructure.
You still have two identity systems to keep synchronized, not one
Federation does not eliminate the mainframe's own identity store; RACF, ACF2, and Top Secret still hold the userids, groups, and profiles that authorization decisions run against. You've added a mapping layer between the IdP and that store, which means joiner/mover/leaver processes now have to keep both systems consistent. This is exactly the kind of ongoing lifecycle problem [identity governance and administration](/blog/identity-governance-administration-iga) programs exist to manage, and mainframe identities belong inside that governance scope rather than off to the side of it.
Removing the native password fallback trades a known risk for a different one
Keeping native password logon available as a fallback after federation preserves an old, weaker attack surface. Removing it entirely improves the security posture but removes the ability to authenticate if the gateway or IdP is unavailable. Most shops keep a narrowly scoped, heavily monitored break-glass credential rather than eliminating the fallback outright, which is itself a residual risk that has to be explicitly accepted and audited.
This does not reduce the number of privileged mainframe credentials that still need native protection
Service accounts, started tasks, and batch jobs generally cannot federate, so they keep relying on native RACF, ACF2, or Top Secret credentials indefinitely. Federating interactive human access does not shrink that population, and treating the project as having solved mainframe credential risk broadly, rather than for interactive users specifically, understates what's left.
The bottom line
RACF, ACF2, and Top Secret were never the reason mainframe authentication sat outside the enterprise's zero-trust and MFA posture. The gap was that mainframe logon lived in its own silo, disconnected from the IdP that already governs risk-based authentication everywhere else. Federating authentication through a gateway, mapping the federated identity to the existing mainframe userid, and replacing password transmission with PassTickets closes that gap without touching the dataset-level and resource-level authorization RACF, ACF2, and Top Secret still do better than any generic IdP. The work that matters most is keeping the identity mapping table accurate, hardening the gateway proportional to the trust it now holds, and being explicit that federating interactive human access is not the same as eliminating mainframe credential risk across service accounts and batch workloads.
Frequently asked questions
What does it mean to federate RACF authentication with a modern identity provider?
It means a user proves who they are to the enterprise IdP over SAML or OAuth, and a gateway then maps that verified identity to the user's existing RACF userid so RACF's own authorization engine still governs dataset and resource access exactly as before.
Do I have to replace RACF, ACF2, or Top Secret to add MFA to mainframe access?
No. The practitioner pattern in 2026 keeps the native security manager in place for authorization and adds a federation layer in front of authentication only, since RACF, ACF2, and Top Secret still perform dataset-level and resource-level access decisions a generic IdP cannot replicate.
How does a federated identity get mapped to a RACF userid?
RACF supports Distributed Identity Filters configured through the RACMAP command, which associate an external identity such as an X.509 certificate Subject DN or Kerberos principal with a specific RACF userid, without ever exchanging the mainframe password.
What is a PassTicket and why does it matter for RACF federation?
A PassTicket is a short-lived, single-use credential generated through RACF's Secured Signon (SSIGNON) class that lets a gateway complete mainframe logon on a user's behalf after IdP authentication, without ever holding or transmitting that user's actual password.
Can ACF2 and Top Secret use the same federation approach as RACF?
The overall pattern applies to all three, but ACF2 and Top Secret lack a direct equivalent to RACF's RACMAP-based Distributed Identity Filters, so the identity mapping table more often lives in the gateway or bridge product rather than in the security manager itself.
What happens to dataset-level and resource-level authorization after federating authentication?
It stays completely unchanged. Federation only changes how a user proves their identity; the RACROUTE REQUEST=AUTH calls (and ACF2/Top Secret equivalents) that decide dataset, resource, and transaction access keep evaluating against the same userid and the same profiles as before.
Sources & references
- Planet Mainframe - Modernizing Mainframe Security: RACF and MFA Misconceptions
- Avatier - Mainframe Identity Modernization: RACF to Zero Trust 2026
- 2025 Arcati Mainframe User Survey (as cited by Planet Mainframe)
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.