Mainframe Modernisation Security Guide: Preserving RACF Controls When Rehosting, Refactoring or Moving to Cloud

Mainframe modernisation projects routinely move decades of business logic and data off z/OS while leaving behind the access control model that protected them. On the mainframe, RACF, ACF2 or Top Secret decide who may run each CICS transaction, read each data set and submit each batch job. When the workload is rehosted on an emulation runtime, refactored into Java or rebuilt as cloud services, those decisions have to be re-created somewhere, and too often they are replaced by a single service account with broad database rights. This guide covers how to inventory the security model before migration, map it to the target, protect data in transit and in test, keep batch and service identities scoped, and prove equivalence before cutover. It is for mainframe security administrators, migration architects and the cloud and IAM teams inheriting the workload.

Key takeaways

• The security database is a migration artefact. Unload and analyse RACF, ACF2 or Top Secret rules at the start of the programme, alongside the code and data inventory, not at cutover.
• Clean before you convert. A one-to-one conversion carries every over-privileged profile and dormant user across; remove what is unused on the mainframe first.
• Every pattern changes where enforcement happens. Rehosting can keep mainframe-style resource checks in the runtime; refactoring moves them into application code and cloud IAM, where they are easy to lose.
• Batch and started task IDs become non-human identities. Give each migrated job its own scoped workload identity instead of one shared runtime account.
• Prove equivalence with tests. Build an access test suite from the mainframe rules and run it against the target before each wave goes live.

Why modernisation weakens access control

On z/OS, access control is external to the application. COBOL programs rarely check permissions themselves; the external security manager (ESM) is called by CICS, IMS, Db2, JES and the data set access methods, and its decisions are logged to SMF. That separation is a strength, and it is also why modernisation breaks it: the code being migrated contains almost none of the security logic. See the Mainframe Identity and RACF Security Guide for how that model works.

• Hidden logic: transaction-level security (for example the RACF TCICSTRN class), data set profiles and surrogate job submission rules sit in the security database, not in source control.
• Old debt: long-lived estates accumulate generic profiles with a permissive UACC, users with SPECIAL or OPERATIONS attributes, and IDs nobody owns. GAO found in 2019 that the ten most critical US federal legacy systems were between 8 and 51 years old, and that only two of the ten agency plans included milestones, a work description and a plan to dispose of the legacy system.
• Skills gap: the people who understand the ESM are often not on the migration team, and the cloud engineers who are do not read RACF.
• Collapsed identity: applications that ran as the end user's RACF ID often end up calling the new database as one application account, removing per-user accountability.

Modernisation patterns and what each does to security

Most programmes combine patterns over several years, so the mainframe ESM and the target controls run side by side. Plan for that hybrid period explicitly: two sources of truth for entitlements, two audit trails and connectors between them. The Cloud Migration Security guide covers landing zone and network design for the target, which this guide does not repeat.

Inventory the security model before migration

1. Unload the security database: for RACF, the IRRDBU00 database unload utility writes the database to a sequential data set of variable-length records (users, groups, connections, data set and general resource profiles, access lists) that can be loaded into a database or analysis tool. ACF2 and Top Secret have their own reporting and extract utilities. Work on the unload, never on the live database.
2. Unload access history: use SMF records (via IRRADU00 for RACF) to see which profiles and permissions were actually used over a representative period, including month-end and year-end batch.
3. Link profiles to applications: map each CICS region, transaction ID, data set high-level qualifier, Db2 plan or package and batch job to the application being migrated, so every wave has a defined set of rules.
4. Classify identities: separate human users, batch job IDs, started task IDs, connector and gateway IDs, and privileged IDs. See the Mainframe Service Accounts and Batch Job Identity Guide.
5. Clean up on the mainframe: revoke dormant users, remove unused permissions, tighten UACC on generic profiles and assign owners. Doing this before migration shrinks the conversion and makes the target easier to test.
6. Record data classification: note which data sets and tables hold personal, payment or regulated data, because that drives encryption, masking and residency decisions for the target.

Mapping mainframe controls to the target

There is no automatic, lossless translation from an ESM to cloud IAM. The mapping is a design exercise, and its output is a requirements document the target must meet. Products named below are documented examples, not recommendations.

• Rehosting runtimes: emulation runtimes typically include an external security facility that relays authorisation requests for mainframe-style resources to one or more security managers. Micro Focus Enterprise Server documentation, for example, describes an External Security Facility with a configurable default response when no security manager recognises a user; set that default to deny.
• Managed cloud runtimes: AWS documents that, for replatformed workloads, its runtime calls IAM authorisation when an application accesses a protected resource derived from the original mainframe environment. Design those IAM policies from the mapped profiles rather than granting the runtime broad rights.
• Refactored code: add an explicit authorisation layer that enforces the transaction-level rules, and test that it does. See the Mainframe and COBOL Application Security Guide for the CICS and Db2 controls the new code must reproduce.

Where identity fits: batch, scheduler and connector identities

Batch is where modernised workloads most often lose least privilege. On z/OS, each job runs under a user ID whose access is set in the ESM, and submission is controlled by SURROGAT profiles. After migration, the same jobs often run under one scheduler or container account with access to everything (ATT&CK T1078 Valid Accounts).

• One identity per job family: give each migrated job stream its own workload identity with access only to its data, mirroring the original job user ID.
• No embedded passwords: JCL converted to scripts or pipeline definitions must not carry database passwords in plaintext (T1552.001 Credentials In Files). Use the platform's secrets manager or workload identity federation. See the Secrets Management Guide.
• Hybrid connectors: during the transition, APIs and replication tools connect the target to z/OS. Map each connector to its own RACF ID with the narrowest access, and prefer PassTickets or certificates over stored passwords.
• Decommission identities with the workload: when a wave is retired on the mainframe, revoke its job and connector IDs there too.

Protecting data during migration and testing

• Transfer: encrypt data set and table extracts in transit and at rest in staging areas (NIST SP 800-53 SC-28), and delete staging copies after load. EBCDIC to ASCII and packed decimal conversion jobs often leave intermediate files behind.
• Test data: refactoring and parallel runs need realistic data. Mask or synthesise personal and payment data before it leaves the production LPAR; test environments are rarely protected to production standard (T1530 Data from Cloud Storage).
• Integrity: reconcile record counts and checksums between source and target, and protect conversion outputs from tampering (T1565.001 Stored Data Manipulation).
• AI-assisted tooling: code analysis and refactoring services read source code, copybooks and sometimes data. AWS, for example, documents human approval of intermediate artefacts such as domain decomposition and wave planning, and notes that data may be processed in a different region. Check residency, retention and access before loading code or data into any such service.
• Keys: mainframe data protected by ICSF-managed keys or data set encryption needs a planned key migration to the target key management service, with separation between key administrators and data administrators.

Proving equivalence and cutting over

1. Build an access test suite: from the cleaned ESM analysis, generate positive tests (this user can run this transaction) and negative tests (this group cannot update this file).
2. Run tests in parallel: run the suite against the target during parallel runs and compare outcomes with the mainframe, including batch job access.
3. Audit-only first: where the target supports it, run new policies in log-only mode for one business cycle, review denies and over-grants, then enforce.
4. Sign-off: have the mainframe security administrator and the application owner sign off the mapping for each wave, as evidence for auditors.
5. Rollback: keep the mainframe profiles intact and the workload runnable until the target has passed a full month-end or year-end cycle.
6. Retire cleanly: after cutover, remove migrated profiles, users and connectors from the ESM, archive the security database unload and SMF history to meet retention rules, and record the decommission.

Detection and measurement

During the hybrid period, collect SMF security records from z/OS and the runtime, IAM and database logs from the target in the same SIEM, with user IDs correlated across both. Watch for access by migrated batch identities outside their job windows, use of break-glass or runtime administrator accounts, access denied spikes after a wave goes live and data exports from staging areas (T1213 Data from Information Repositories).

• Rule coverage: percentage of in-scope ESM profiles mapped to a target control and covered by a test.
• Cleanup: number of dormant users and unused permissions removed before conversion.
• Identity granularity: number of migrated jobs and services sharing an identity, trending to zero.
• Equivalence: access test pass rate per wave before go-live (target 100 percent, with documented exceptions).
• Secrets: plaintext credentials found in converted JCL, scripts and configuration (target zero).
• Decommissioning: ESM profiles and IDs still active for workloads already retired.

Common failure patterns

• Security database left to the end: code and data migrate first, and access control is designed in the last month under deadline pressure.
• Straight conversion: every profile and user is imported, including dormant IDs and generic profiles with permissive UACC.
• One runtime account: the rehosted or refactored application accesses all data as a single service account, losing per-user accountability.
• Warning mode forever: profiles in WARNING mode on z/OS become permanent allow rules on the target.
• Production data in test: unmasked extracts used for parallel runs sit in cloud storage with broad access.
• Orphaned mainframe access: workloads move, but their RACF IDs and connector accounts stay active on z/OS for years.

Framework mapping

Practitioner checklist

• Put the ESM analysis on the migration plan from day one, with a named mainframe security owner.
• Unload the security database and SMF history and map profiles to applications and waves.
• Remove dormant users, unused permissions and permissive UACC before conversion.
• Write a mapping of each resource class and profile to its target control and get it signed off.
• Set the default response for unrecognised users in any rehosting runtime to deny.
• Give each migrated job family and connector its own scoped identity with no embedded passwords.
• Mask or synthesise sensitive data before it leaves the production mainframe for test or parallel runs.
• Run an access test suite against the target and keep log-only mode for one business cycle.
• Keep mainframe access intact for rollback until a full period-end has run on the target.
• Revoke migrated profiles, IDs and connectors on z/OS when each workload is retired.

Standards and references

• IBM: z/OS Security Server RACF, Running the database unload utility
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• GAO: Information Technology, Agencies Need to Develop Modernization Plans for Critical Legacy Systems (GAO-19-471)
• AWS: Security in AWS Mainframe Modernization
• AWS: AWS Transform for mainframe
• Micro Focus: About the External Security Facility (ESF)

Related NHI Mgmt Group resources: Mainframe Identity and RACF Security Guide · Mainframe Service Accounts and Batch Job Identity Guide · IBM z/OS Security Hardening Guide · Cloud Migration Security · Legacy Application Security