RACF vs. ACF2: Key Differences and How to Choose the Right Mainframe Access Control
RACF vs. ACF2: a 2026 mainframe security comparison covering features, scalability, cost, and how to choose the right option for your z/OS environment.

Two access control systems still anchor the security perimeter on most IBM mainframe environments: RACF (Resource Access Control Facility) and ACF2 (Access Control Facility 2). Both protect z/OS resources. Both have decades of production heritage in financial services, government, healthcare, and the other industries where mainframe still does the heavy lifting. But they come from different places — RACF from IBM as a native z/OS component, ACF2 from SKK Inc. in the 1970s and now from Broadcom (via Computer Associates) as a separately-licensed product — and that lineage shapes how each one behaves under load, how each one integrates, and what each one actually costs to run.
This is a 2026 refresh of a piece we've been pointed at for years when customers ask, "Which mainframe ESM should we be on?" The honest answer is usually "the one you already have" — but the longer answer is worth the read, because the differences matter when you're making a 10-year commitment, integrating mainframe identity with the rest of your IAM stack, or budgeting around Broadcom's licensing curve. We work with both daily on the Avatier platform side, and what follows is what we tell our own customers.
Six dimensions, two products. Each row captures the structural character of each ESM — the right choice depends on which dimensions weigh hardest in your environment, which the rest of this guide unpacks.
The six dimensions that matter
When teams ask us to compare RACF and ACF2 head-to-head, the conversation almost always reduces to six dimensions. Each one has a defensible "winner," but most of them tilt slightly rather than decisively.
Security features
RACF and ACF2 both deliver the security primitives you expect from an enterprise external security manager (ESM): authentication, authorization, resource protection, and audit logging. RACF stays close to IBM's z/OS security model and integrates deeply with the operating system's RACROUTE macros, which means policy decisions happen inside the kernel rather than as an external callout. ACF2 is built around a more dynamic policy engine: rules can include logic that fires on context (job class, time of day, source LU), and the product was designed from the start to support behavior-based threat detection. If your security posture needs to react to anomalous access patterns in real time, ACF2's design gives you that capability natively. If your posture is more about clean, durable, IBM-aligned policy that doesn't change often, RACF tends to feel more natural to administer.
Ease of use
ACF2 is generally considered easier to install and easier to administer day-to-day. Its rule syntax is more compact, the audit reports are arguably more readable, and the documentation is consolidated under Broadcom. RACF has a steeper initial curve — there are more concepts (profiles, classes, generic vs discrete, conditional access lists) and the command surface is larger — but it pays you back with a vast community, decades of IBM Redbooks, and an ecosystem of third-party tooling. Teams that have been running RACF for ten years usually don't experience it as "hard"; teams onboarding fresh do. Get the right RACF essential configuration steps in place early and most of the ramp pain goes away.
Scalability
Both products scale to enterprise volumes — we've seen each one handling tens of thousands of users and millions of access decisions per day. RACF's z/OS integration gives it an edge under sustained heavy load because policy evaluation happens close to the resource manager. ACF2 can match RACF on raw throughput, but as the rule set grows in complexity (lots of context-aware rules, many rule lines per resource type), evaluation latency can creep up. We've measured ACF2 environments adding 5-10% to the auth path under heavy policy load — useful capability, but not free.
Performance
Performance follows scalability. RACF is part of z/OS, so it benefits from being inside the operating system rather than alongside it. ACF2 runs on z/OS but as a separate subsystem, which introduces a small but measurable overhead — usually invisible at normal load but visible at peak. ACF2 supports caching and policy optimization to compensate, and in well-tuned environments the gap is negligible. Pick performance as a deciding factor only when you've actually measured a bottleneck.
Compatibility
RACF is the IBM-native option and gets first-class treatment from every IBM mainframe component — DB2, CICS, IMS, MQ, USS — without thinking about it. ACF2 is fully compatible with z/OS but requires Broadcom's compatibility layer to integrate with non-IBM tooling, and you should validate vendor support for ACF2 the same way you'd validate any third-party security manager. For mixed mainframe environments that include AS400/IBM i alongside z/OS, the integration story gets more nuanced — see our note on AS400 and iSeries access control if that applies to your shop.
Cost considerations
RACF ships with z/OS at no incremental license cost. That's the simplest statement we can make about it. ACF2 is licensed separately by Broadcom, with pricing tied to MIPS (Million Instructions Per Second — the standard mainframe capacity unit), user count, and selected modules. Broadcom does not publish ACF2 pricing, but in the deals we've seen, an enterprise ACF2 license can run from low six figures to seven figures annually depending on capacity. That's a meaningful TCO delta over ten years — even if ACF2 saves administrator time, the license differential rarely closes. Cost alone shouldn't decide the question, but it should be on the table.
RACF's security capabilities in depth
RACF is built around a small number of core capabilities, each one anchored in the z/OS security model.
User authentication is the foundation. RACF authenticates users against the RACF database, supports password phrases up to 100 characters, integrates with Kerberos and digital certificates, and exposes APIs for application-level identity verification. Multi-factor authentication via IBM Multi-Factor Authentication for z/OS extends this further — RACF can require a second factor based on profile, application, or risk context.
Access control is where RACF earns its reputation. Resources are organized into classes (DATASET, FACILITY, SURROGAT, etc.), and access is granted via profile permissions and conditional access lists. The model lets you express both broad rules ("everyone in this group can read these datasets") and surgical ones ("this specific user can update this specific profile only when running this specific job"). For a deeper walk through the model, see demystifying RACF for user access control.
Audit and logging runs through SMF (System Management Facility), z/OS's central audit record stream. RACF emits SMF type 80 records for every security-relevant event, and most enterprise SIEMs (Splunk, IBM QRadar, Sentinel via connector) ingest SMF natively. Audit configuration is granular — you can log all access, all failed access, just first-of-day, or specific event types per resource class.
Resource protection extends beyond datasets. RACF protects general resources (CICS transactions, DB2 tables and packages, MQ queues, USS files, JES jobs, network resources via SERVAUTH), which means a single ESM defines the access policy for essentially every controllable thing on the mainframe. For most enterprises, RACF replaces what would otherwise be a half-dozen point security tools.
Security policy management is the day-to-day operational layer — provisioning users, managing user groups and permissions in RACF, rotating credentials, attesting access. The administrative experience is command-driven (TSO panels, RACF commands like ADDUSER, PERMIT, SETROPTS), but third-party GUIs and identity governance integrations bring this layer into a modern management experience.
ACF2's security capabilities in depth
ACF2 — originally Access Control Facility 2 from SKK Inc., later CA-ACF2, now Broadcom ACF2 — is built around the same security primitives as RACF but with a different design philosophy: rules are dynamic, evaluation is rule-engine driven, and context-aware policy is a first-class concept rather than an extension.
Granular access control is ACF2's most-cited strength. ACF2 rules operate on logonids (the ACF2 equivalent of a RACF user) and resources via a compact, expressive syntax. A single rule line can express conditional access ("permit READ if source is LU01 and time is between 0800 and 1700"), and the rule engine evaluates these in real time on every access decision. The same logic in RACF is possible but takes more administration.
Dynamic security rules let ACF2 react to context that's only known at access time. Rules can reference job class, source terminal, application, calendar, even values pulled from the security context of the current job step. This is what makes ACF2 attractive in environments where security policy needs to be situational rather than static — government-classified workloads, financial trading floors, healthcare systems with shift-based access patterns.
Behavior-based threat detection is built into the ACF2 policy model. The product can flag access patterns that deviate from a user's normal behavior (new resource classes accessed, unusual time windows, sudden volume changes) and either alert, log, or block depending on policy. RACF can be augmented with separate tooling to do similar work; ACF2 ships with it native.
Comprehensive auditing in ACF2 covers the same scope as RACF — every security decision generates an audit record, and those records flow into SMF or ACF2's own audit dataset depending on configuration. Reports are organized around logonids, rules, and resources; the audit posture is well-suited to compliance frameworks that demand both event-level granularity and aggregate behavior analysis.
Integration is the area where ACF2 takes the most setup. Broadcom maintains compatibility layers for the major z/OS subsystems (DB2, CICS, IMS, MQ), but you should validate third-party tooling support explicitly. Modern identity governance integrations into ACF2 generally go through Broadcom's web services interfaces or LDAP — see the integration section below.
A pragmatic decision lens. Most enterprises follow the upper branches; the greenfield branch in the middle is rare in 2026 but real.
How to choose between them
For most enterprises, the choice has already been made — either by a decision a decade ago or by which mainframe stack you inherited in an acquisition. The honest question is rarely "which should we pick?" but "should we switch?" Both questions reduce to the same six factors.
Security requirements. If your policy needs are mostly static — durable role definitions, slow-changing access lists, periodic attestation — RACF's model is a natural fit. If your policy needs to respond to context in real time (time-of-day, source-terminal, behavior-based), ACF2's rule engine handles this with less administrative overhead.
Existing mainframe environment. If your shop is IBM-aligned end-to-end (z/OS + DB2 + CICS + IMS, IBM SIEM, IBM tooling), RACF is the lower-friction choice. If your stack already includes substantial Broadcom presence (Endevor, CA-7, the ESP scheduler), ACF2 fits the same vendor relationship and probably shares contract terms.
Mainframe expertise. Look at your team. RACF talent is more available in the labor market because RACF is the default. ACF2 specialists are rarer but typically experienced — Broadcom has consolidated the ACF2 community and the docs are good. If you're hiring fresh into mainframe security, RACF is easier to staff.
Scalability and performance. Both scale. Pick this dimension as a tiebreaker only if you've measured a current bottleneck. For new deployments, RACF's z/OS-native model gives you slightly less to tune.
Integration and compatibility. This is increasingly the deciding factor, because mainframe identity no longer lives in isolation. Whatever ESM you choose, modern enterprises bring mainframe identity into the same governance lifecycle as cloud and on-prem workloads. Platforms like Avatier Identity Anywhere integrate with both RACF and ACF2 via standard connectors, so the mainframe stops being an identity governance island.
Cost and budget. RACF is no incremental license. ACF2 is six- to seven-figure annual licensing. Over a ten-year horizon, the cost differential is large. ACF2 buyers usually justify the spend on operational savings (less administrative time) or on installed-base inertia. New buyers, in 2026, rarely choose ACF2 on cost grounds.
A simple decision lens: if you're already on RACF, you almost certainly stay. If you're already on ACF2 and the Broadcom contract is up for renewal, run the math — including the migration cost, which is typically 6-18 months and several hundred thousand dollars in services for a large enterprise. If you're on neither and standing up a new mainframe environment in 2026 (rare but it happens), RACF is the default unless you have a specific reason to pick ACF2.
Whatever ESM you run, the integration paths are well-trodden. The mainframe stops being an identity island the moment you wire it into the same provisioning, attestation, and audit lifecycle as the rest of the stack.
Integration with modern identity governance
The most important shift in mainframe security over the last five years isn't inside the ESM — it's around it. Mainframe identity used to live in a parallel universe from the rest of the IAM stack. Joiner/mover/leaver workflows in your HRIS or Workday environment did not touch RACF. ACF2 logonid creation was a separate ticket queue. Attestation of mainframe access ran on its own quarterly cadence, usually via spreadsheets. That gap is closing.
RACF integrates with modern IAM platforms via a few well-understood paths. RACF Remote Sharing Facility (RRSF) lets you propagate user and profile updates across z/OS systems. The RACF database can be read and written via published APIs and the IRRDBU00 utility. LDAP bridges (IBM Security Directory Server with the RACF backend, third-party LDAP-to-RACF gateways) expose RACF as a directory service that any standards-based IAM platform can read and write. For more on the underlying model, see unlocking the secrets of RACF.
ACF2 integrates via Broadcom's published APIs, an LDAP interface, and through provisioning connectors maintained by major IAM vendors. The integration is real but typically requires more vendor coordination than RACF because ACF2 ships less standardization in the connector layer.
What this means operationally: a 2026 mainframe security architecture brings RACF or ACF2 into the same provisioning, deprovisioning, attestation, and audit lifecycle as your cloud and on-prem workloads. New employees get mainframe access through the same workflow as Salesforce access. Departing employees lose mainframe access on the same SLA as their email account. Quarterly attestation covers RACF profiles next to AWS roles. The mainframe is no longer an island, and the operational improvement is significant — most enterprises that close this gap report a reduction in orphaned mainframe accounts and a measurable improvement in audit posture.
That's the larger story behind the RACF-vs-ACF2 decision: whichever ESM you choose, treat it as a node in your identity governance graph, not a separate kingdom. The question stops being "which ESM is better?" and starts being "how do we bring mainframe access into the same lifecycle as everything else?"
If you're working through that integration question, Avatier Identity Anywhere connects RACF and ACF2 into modern workforce identity governance without forcing you to change ESMs. That's usually the practical answer — and it's the shift this blog covers in depth across the five pillars of credential governance.
Frequently asked questions
What is RACF?
IBM's Resource Access Control Facility — the security management system for z/OS mainframes. RACF handles user authentication, resource access control, audit logging, and security policy enforcement on IBM mainframe environments.
What is ACF2?
Access Control Facility 2 — a mainframe security management product currently owned by Broadcom (acquired from CA Technologies). ACF2 protects mainframe resources via fine-grained access control, dynamic security rules, and behavioral auditing. It runs on z/OS but is a separate licensed product, not a native IBM tool.
Is RACF or ACF2 better?
Neither is universally better — they target different organizational profiles. RACF is the better fit when z/OS integration depth, native IBM support, and large-scale throughput are priorities. ACF2 is the better fit when you need finer-grained access controls, dynamic security rules, behavior-based threat detection, or you're already on a Broadcom security stack.
Is ACF2 still supported?
Yes. Broadcom continues to actively maintain ACF2 as part of its Mainframe Software portfolio. Updates ship regularly.
Can RACF and ACF2 coexist on the same mainframe?
Technically only one external security manager (ESM) is active for z/OS at a time. Migrating between them is a planned, multi-phase project — typically 6 to 18 months for a large enterprise.
How does RACF integrate with modern identity governance?
RACF integrates with modern IAM platforms (Avatier Identity Anywhere, SailPoint, Saviynt, etc.) via standard interfaces — typically RACF database connectors, LDAP bridges, or REST APIs against IBM RACF Remote Sharing Facility. The goal is to bring mainframe identity into the same governance lifecycle as cloud and on-prem workloads.
What does ACF2 cost?
ACF2 is licensed separately from z/OS, with pricing determined by Broadcom based on MIPS (Million Instructions Per Second), number of users, and add-on modules. Pricing is not published. RACF, by contrast, is included with z/OS at no additional license cost.
Should we migrate from ACF2 to RACF (or vice versa)?
Most enterprises stay with whichever ESM they already deploy because migration is operationally expensive (6 to 18 months) and the security parity between the two is close enough that switching rarely produces measurable security gain. Migrate only when there's a clear strategic driver — Broadcom contract renegotiation, IBM-only consolidation, or a major modernization initiative.
ABOUT THE AUTHOR

Marcelo Victor is an AI Platform Engineer at Avatier, working on the identity platform's mainframe and legacy integration layer, including RACF, ACF2, and authentication protocol stacks.
More from RACF & Mainframe

What Storm-2949 Actually Broke: Identity Governance, Not Self-Service Password Reset
Microsoft's Storm-2949 disclosure exposed an identity governance gap, not a password gap. What service-principal hygiene, JIT RBAC, and lifecycle attestation would have caught.