Mainframe Security Guide: RACF, ACF2 and Top Secret

Mainframes still run payments, policies, claims and reservations for many large organisations, yet their identities are often governed by a few specialists, outside the identity programme that covers everything else. On IBM z/OS every access decision passes through the System Authorization Facility (SAF) to an external security manager: IBM RACF (Resource Access Control Facility), or Broadcom's ACF2 or Top Secret (formerly CA ACF2 and CA Top Secret). This guide explains how mainframe identity works across all three, which privileged attributes and service identities carry most risk, how to secure CICS, IMS, Db2 for z/OS, TSO and z/OS UNIX access, and how to audit it with SMF records. It is for mainframe security administrators, IAM and PAM teams bringing the platform into scope, and auditors.

Key takeaways

Privileged attributes are the crown jewels. RACF SPECIAL "allows the user to issue all RACF commands" and OPERATIONS lets a user "perform any maintenance operations on RACF-protected resources"; ACF2 SECURITY and NON-CNCL and Top Secret MSCA and SCA ACIDs carry equivalent power.
Most mainframe identities are not people. Started task, batch, CICS region, Db2, FTP and connector IDs outnumber human users and should be PROTECTED (no password) wherever they never log on interactively.
Delegation is a hidden privilege path. Surrogate job submission (SURROGAT class), TRUSTED started tasks and PassTickets let one identity act as another; review them as carefully as SPECIAL.
Separate administration from audit. In RACF "not even the security administrator with the SPECIAL attribute can execute auditor functions"; keep AUDITOR and ROAUDIT holders independent and send SMF type 80 records to the SIEM.
Bring the mainframe into enterprise identity. Joiner-mover-leaver, access reviews, MFA and PAM should reach z/OS through connectors and IBM Z MFA, not spreadsheets.

How mainframe identity works on z/OS

z/OS subsystems (TSO, batch, CICS, IMS, Db2, z/OS UNIX System Services, FTP, MQ) do not make their own access decisions. They call SAF, which passes the request to the external security manager (ESM). The ESM authenticates the user, builds a security context (in RACF, the ACEE) and decides mainframe access to data sets and general resources. The three products use different vocabularies for the same ideas.

Concept	IBM RACF	ACF2 (Broadcom)	Top Secret (Broadcom)
Identity record	User profile with segments (TSO, OMVS, CICS)	Logonid record	ACID (accessor ID) of type USER
Data protection	Data set profiles with UACC and access list	Access rules per high-level qualifier	Resources owned by a department, permitted to ACIDs
Security administrator	SPECIAL or group-SPECIAL	SECURITY privilege, limited by scope records	MSCA, then SCA, ZCA, VCA, DCA control ACIDs
Auditor	AUDITOR (sets audit controls); ROAUDIT (read only)	AUDIT privilege, "comparable to RACF's ROAUDIT"	Audit authority on a control ACID
Access bypass	OPERATIONS	NON-CNCL, READALL	Bypass attributes on the ACID
Started tasks	STARTED class or ICHRIN03 table	Logonid with STC privilege	STC record mapping procedure to ACID

RACF names are used below as the reference; the principles apply equally to ACF2 and Top Secret security. When migrating between ESMs, map these concepts first, because a straight conversion carries every over-privileged record across.

Privileged attributes and mainframe privileged access

Mainframe privileged access is mostly defined by attributes on the identity record. System-level attributes apply to the entire system; group-level attributes (group-SPECIAL, group-AUDITOR, group-OPERATIONS, assigned with CONNECT) apply only within a group's scope.

RACF attribute	What it allows	Control
SPECIAL	All RACF commands: create users, reset passwords, change profiles and SETROPTS	Very few holders, PAM checkout, every command logged (SAUDIT)
group-SPECIAL	Administer users and profiles within a group's scope	Use for help desk and delegated admins; review scope quarterly
OPERATIONS	Access to data sets without being on the access list	Remove from people; use STGADMIN profiles for storage work; OPERAUDIT on
AUDITOR	Set and list audit controls (SETROPTS logging, UAUDIT)	Only the independent monitoring function, never administrators
ROAUDIT	Read-only auditing, without changing audit controls	Preferred for auditors and monitoring tools
CLAUTH(USER)	"Define profiles in a specific RACF class", here new user IDs	Only the provisioning connector and security team

RACF special attribute holders: list them from a database unload (IRRDBU00), record an owner and reason for each, and alert on any ALTUSER that adds SPECIAL, OPERATIONS or AUDITOR.
RACF operations attribute: IBM documents ways of "limiting the capabilities of the OPERATIONS attribute". Most storage administration can be done through FACILITY class STGADMIN profiles for DFSMS functions, so OPERATIONS can leave day-to-day accounts.
ACF2 and Top Secret equivalents: treat SECURITY, ACCOUNT, NON-CNCL and READALL, and MSCA and SCA ACIDs and bypass attributes, as tier 0. Broadcom notes NON-CNCL is not even checked "If there is a rule that allows access", and access matching the MAINT environment is not logged, so NON-CNCL logging alone is not enough.
Emergency access: keep a sealed break-glass ID with SPECIAL for database recovery, tested and alerted on use. See the Break-Glass Account Guide.

For checkout, approval and session recording across platforms, see the Privileged Access Management Guide.

Mainframe service accounts and started task user IDs

Started tasks (JES2, TCP/IP, CICS regions, Db2, the FTP daemon), scheduled batch, file transfer and integrations all run under user IDs. These mainframe service accounts are the largest identity population on most systems.

Started task user ID: assign it through the STARTED class (STDATA segment with USER and GROUP). IBM notes the class can be changed with RDEFINE and RALTER without code changes or an IPL, unlike the older ICHRIN03 table. Map the catch-all profile to a low-privilege ID with TRACE, so new procedures are noticed rather than inheriting power.
TRUSTED and PRIVILEGED: these STDATA flags let a started task bypass most authorisation checks. DISA STIG rule RACF-ES-000130 (V-223661) requires that "started tasks defined with the trusted attribute must be justified" against IBM's approved list, and treats PRIVILEGED as a finding; the fix is STDATA(TRUSTED(NO)). The change applies only after the task is recycled, because the ACEE is built at address space start.
PROTECTED user IDs: define started task, batch and server IDs with no password or password phrase, so they cannot log on to TSO or be reset into use. This removes the commonest weakness: a shared batch password known to operators and embedded in scripts.
Batch and scheduler IDs: give each application its own ID, restrict which scheduler definitions can use it, and review the surrogate permits that make this possible.
Ownership: every service ID needs a named owner, purpose and review date. See the Service Account Security Guide.

Mainframe surrogate access

Surrogate authority lets one identity start work as another without its password. In the SURROGAT class, READ on a profile named userid.SUBMIT lets the permitted user submit jobs that run as that ID. CICS uses the same class: a surrogate user has "the authority to start work on behalf of another user (the execution user)", through profiles such as userid.DFHSTART, userid.DFHINSTL and userid.DFHEXCI, and IBM recommends always enabling surrogate checking (the XUSER parameter). READ on a .SUBMIT profile for a production ID is equivalent to holding that ID, so review it as privileged access.

RACF PassTickets

A PassTicket "provides an alternative to the RACF password and password phrase": a one-time credential generated from a secured signon key held in a PTKTDATA class profile, so portals, middleware and connectors can sign users on to CICS, IMS or TSO without passwords crossing the network. IBM documents a "plus-or-minus-10-minute PassTicket replay protection" window, which can be switched off per application with NO REPLAY PROTECTION in APPLDATA. Any application that can generate PassTickets can impersonate every user of the target application, so protect keys in ICSF rather than masked in the database, restrict who can generate them, keep replay protection on and synchronise clocks.

Securing CICS, IMS, Db2, TSO and z/OS UNIX access

Subsystem	Identities involved	Key controls
CICS security	Region user ID, default user ID, terminal users, surrogates, inter-region links	SEC=YES; transaction security via TCICSTRN and GCICSTRN; XUSER surrogate checking; minimal default user
IMS security	Control and dependent region IDs, terminal users, OTMA clients	Transaction and command authorisation through RACF classes such as TIMS; OTMA client security
Db2 for z/OS	Db2 address spaces, plan and package owners, DRDA users, SYSADM holders	DSNR class for connections; optional RACF access control module; minimal SYSADM; SECADM separate from DBADM
TSO access	Interactive users, system programmers, operators	TSOPROC, ACCTNUM and TSOAUTH profiles; restrict OPER and ACCT authority; MFA; idle timeouts
z/OS UNIX System Services	IDs with an OMVS segment, daemons, UID 0 holders	No UID 0 for people; BPX.SUPERUSER only where justified; UNIXPRIV for specific privileges; protect BPX.DAEMON and BPX.SERVER
Mainframe file transfer	FTP daemon, transfer product IDs, partner IDs, SFTP keys	No anonymous FTP; TLS through AT-TLS; per-partner IDs limited to staging data sets

CICS access: the region user ID needs access to every resource the region opens, so keep transaction-level checks on; otherwise a terminal user reaches data merely because the region can.
File transfer as exfiltration route: run each flow under its own PROTECTED ID, encrypt in transit and log every transfer. SFTP keys are machine credentials: see the SSH Key Management Guide.
Mainframe utility access: AMASPZAP (superzap), DFSMSdss and IDCAMS can read or change data below normal controls. Protect powerful programs with PROGRAM class profiles, DFSMS administrator functions with STGADMIN.* FACILITY profiles, and APF-authorised libraries with UPDATE limited to system programmers.

Mainframe data security, the RACF database and cryptography

Default deny: run with SETROPTS PROTECTALL, set UACC(NONE) on generic profiles and avoid ID(*) access to production data. Review profiles in WARNING mode, which logs but allows.
RACF database: restrict UPDATE on the primary and backup database data sets to the security team and protect offline copies equally. Use IRRDBU00 unloads for analysis instead of broad read access.
Passwords: use password phrases, SETROPTS PASSWORD syntax and revocation rules, SETROPTS INACTIVE for dormant IDs, and the KDFAES method for stored passwords (IBM: "Specifying the encryption method for user passwords").
ICSF: the Integrated Cryptographic Service Facility holds the key stores (CKDS, PKDS, TKDS) and callable services used by data set encryption, TLS, PassTickets and applications. IBM states "The CSFKEYS class controls access to cryptographic keys", with profiles named after the key label, and "The CSFSERV class controls access to ICSF services and ICSF TSO panel utilities"; XFACILIT profiles define a Key Store Policy.
Mainframe cryptography in practice: z/OS data set encryption assigns a key label to each encrypted data set, so reading the data needs both data set access and READ on the CSFKEYS profile. Storage administrators can then move encrypted data without reading it. Keep CSFKEYS UACC(NONE) and give key custodians, not administrators, control of key functions. See the Cryptographic Key Management Guide.

Mainframe multi factor authentication

IBM Multi-Factor Authentication for z/OS (now IBM Z Multi-Factor Authentication, IBM Z MFA) "requires that multiple authentication factors be presented during logon", and "Each authentication factor must be from a separate category of credential types". Factor definitions live in the RACF MFADEF class and each user's MFA settings in the user profile, so the ESM enforces MFA whether logon comes through TSO, CICS or z/OS UNIX.

Order: users with SPECIAL, OPERATIONS, AUDITOR, UID 0 or BPX.SUPERUSER first, then all TSO users, then application sign-on.
Application bypass: IBM documents an "MFA application bypass" for applications that cannot handle prompts. Keep the list short, owned and reviewed; each entry is an MFA gap.
Service identities: MFA is for people. Service IDs should be PROTECTED, authenticating with certificates or PassTickets where needed. See the MFA Guide.

Mainframe segmentation and connectors

Mainframe segmentation: restrict TN3270 (over TLS), FTP, SSH, Db2 DRDA, MQ and z/OSMF ports to known source networks with z/OS Communications Server IP filtering or firewalls; isolate the hardware management console network; keep test LPARs on separate security databases from production; route administrators through a PAM jump host.
Mainframe connector accounts: IGA, PAM and SIEM tools reach RACF through agents, LDAP (the SDBM back end) or command interfaces, and data integration tools pull data through batch connectors. Give a provisioning connector group-SPECIAL over the groups it manages plus CLAUTH(USER), not system SPECIAL; make it PROTECTED, authenticate it with a certificate or PassTicket, and alert on commands outside the provisioning schedule.
Joiner-mover-leaver: drive RACF user creation, connections and revocation from the HR-driven lifecycle, not tickets. See the Joiner-Mover-Leaver Guide.

RACF audit, SMF records and detection

RACF writes audit events as SMF type 80 records, which IRRADU00 unloads into a readable format. What is logged is set by the AUDITOR.

Setting	What it logs	Recommendation
SETROPTS SAUDIT	Commands from SPECIAL and group-SPECIAL users	On (initialisation default); alert on critical commands
SETROPTS CMDVIOL	RACF command violations	On; repeated violations suggest probing
SETROPTS OPERAUDIT	Accesses granted through OPERATIONS	On (NOOPERAUDIT is the default)
SETROPTS LOGOPTIONS	ALWAYS, NEVER, SUCCESSES, FAILURES or DEFAULT per class	FAILURES for all active classes; ALWAYS for SURROGAT, PTKTDATA and CSFKEYS where volume allows
SETROPTS AUDIT(class)	Profile changes in the class	AUDIT(*) or at least USER, GROUP, DATASET, FACILITY
ALTUSER UAUDIT	Every command and access by one user	Privileged, break-glass and connector IDs

Alert on: SPECIAL, OPERATIONS or AUDITOR added; new permits on SURROGAT, PTKTDATA, CSFKEYS, BPX.SUPERUSER and database profiles; SETROPTS changes that switch off logging or classes; logons by revoked or break-glass IDs; interactive logon by service IDs; bursts of violations.
SMF records off the platform: forward type 80 events in near real time to the SIEM rather than relying on daily reports. IBM zSecure (Audit, Admin and Alert) is IBM's toolset for RACF analysis and real-time alerting; ACF2 and Top Secret sites use ESM reports and SMF forwarding. See the SIEM Guide.
Separation: SPECIAL users must never control their own logging. See the Segregation of Duties Guide.

Metrics: number of IDs with system SPECIAL, OPERATIONS or AUDITOR and the share under PAM checkout; percentage of service IDs that are PROTECTED; MFA coverage of privileged and TSO users; TRUSTED or PRIVILEGED started tasks not on IBM's list (target zero); days from HR leaver event to revoke; time for a privileged change to reach the SIEM.

Implementation roadmap

Inventory: unload the database (IRRDBU00, or the ACF2 and Top Secret list functions run off-peak) and list privileged attributes, service IDs, TRUSTED started tasks, SURROGAT and PTKTDATA permits and CSFKEYS profiles. Assign owners.
Visibility first: set SAUDIT, CMDVIOL, OPERAUDIT and failure logging, forward SMF to the SIEM and build alerts. More logging breaks nothing.
Reduce standing privilege: group-SPECIAL for delegated admins, STGADMIN instead of OPERATIONS, AUDITOR to monitoring, ROAUDIT to auditors, remaining SPECIAL behind PAM.
Protect service identities: PROTECTED IDs, justified TRUSTED, narrow SURROGAT and PassTicket permits. Test in a development LPAR, then change one application at a time in production with the previous profile saved, so rollback is one command and a RACLIST refresh.
Tighten data and crypto access: PROTECTALL (after reviewing which data sets lack profiles), UACC(NONE), CSFKEYS and CSFSERV, data set encryption. Pilot new restrictive profiles in WARNING mode, review, then enforce.
Deploy MFA and integrate lifecycle: privileged users first, then connect the ESM to IGA for joiner-mover-leaver and quarterly reviews. See the Access Reviews Guide.

Small vs large estates: a single-LPAR site can do most of this with ESM commands, scheduled unload reports and SMF forwarding. A multi-sysplex estate with several databases needs central analysis tooling, connector-based IGA and formal change control for SETROPTS, because one command applies everywhere a database is shared.

Common failure patterns

SPECIAL as a job title: every security analyst and several system programmers hold system SPECIAL permanently, and the same people hold AUDITOR.
Catch-all started task profile: unknown procedures map to a powerful ID, so a procedure planted in a PROCLIB inherits it.
Service IDs with passwords: batch and FTP IDs with non-expiring passwords in JCL and partner systems, able to log on to TSO.
Forgotten delegation: a retired portal still holds a PassTicket key and SURROGAT access to production IDs.
OPERATIONS without OPERAUDIT: storage administrators read any data set and nothing records it.
Mainframe outside the identity programme: leavers revoked weeks late from tickets, and access reviews of cryptic IDs managers cannot interpret.

Framework mapping

Control area	NIST SP 800-53 Rev. 5	CIS Controls v8.1	ISO/IEC 27001:2022 Annex A
Account lifecycle and service IDs	AC-2	5.1, 5.3, 6.1, 6.2	A.5.16, A.5.18
Privileged attributes	AC-6(1), AC-6(2), AC-6(5), AC-6(9)	5.4	A.8.2
Administration vs audit	AC-5	6.8	A.5.3
Authentication and MFA	IA-2(1), IA-2(2), IA-5	6.5	A.8.5
SMF logging and review	AU-2, AU-6, AU-9, AU-12	8.2, 8.11	A.8.15, A.8.16
ICSF and encryption	SC-12, SC-13, SC-28	3.11	A.8.24

The DISA STIGs for IBM z/OS with RACF, ACF2 and Top Secret turn these controls into specific checks and are a useful baseline outside government too.

Practitioner checklist

List every holder of system SPECIAL, OPERATIONS, AUDITOR, ROAUDIT and CLAUTH(USER), or ACF2 and Top Secret equivalents, with owner and reason.
Move delegated administration to group-SPECIAL and storage work to STGADMIN; put remaining SPECIAL IDs behind PAM.
Give AUDITOR only to monitoring and ROAUDIT to auditors; never combine AUDITOR with SPECIAL.
Make every started task, batch, FTP and connector ID PROTECTED; justify or remove every TRUSTED started task.
Review SURROGAT permits, PTKTDATA profiles and PassTicket generators; keep replay protection on.
Run with PROTECTALL and UACC(NONE), protect the RACF database, restrict CSFKEYS and CSFSERV.
Enforce IBM Z MFA for privileged and TSO users with a short bypass list.
Turn on SAUDIT, CMDVIOL, OPERAUDIT and failure logging; forward SMF type 80 records to the SIEM.
Connect the ESM to IGA for joiner-mover-leaver and quarterly privileged reviews.