RACF User ID Containment is a new RACF feature that gives you the ability to instantly “quarantine” a user ID even if that user already has active sessions running. If you’ve ever handled a suspected compromise on z/OS, you know how frustrating that gap has been: revoking a user stops new logons and job submissions, but existing TSO/E sessions, jobs, and server subtasks keep running with full authority.

Starting in z/OS 3.2 (and in z/OS 3.1 with the required PTFs for RACF APAR OA67286 and SAF APAR OA67288), RACF closes this gap and gives administrators a fast, reliable way to cut off access immediately. This article walks through how containment works, how to use it safely, and what to watch out for when deploying it. It’s written for RACF and z/OS system administrators responsible for user management, incident response, and day‑to‑day security operations.

What “Containment” does?

Think of containment as a stronger, smarter version of REVOKE. When you contain a user, RACF assigns the CONTAINED attribute and adds the ID to an in‑storage containment list. From that point on, all authorization checks and RACF commands will fail due to containment, and all verification (VERIFY, INITACEE, etc.) will fail due to revocation. There’s no need to hunt down jobs, logons, or address spaces. RACF simply denies the requests as they occur.

This is what makes containment such a powerful tool for real‑time incident response: it gives you a “stop now” button you can rely on.

Availability and prerequisites:

User ID Containment is available in:

• z/OS 3.2: base
• z/OS 3.1: enabled via
• PTFs shipped via RACF APAR OA67286 (User Containment support)
• PTFs shipped via SAF APAR OA67288 (macro-level support)

Once these PTFs are applied, all commands, attributes, auditing behavior, and ENF signaling are fully supported.

Two operational considerations:

Two things you need to keep in mind before using containment operationally:

1. The RACF address space must be active when adding or removing IDs from containment.
   After the user is contained, enforcement continues even if the RACF address space ends unexpectedly.
2. All systems in a shared RACF database environment must support containment. Older systems without the containment PTFs will ignore the setting, which can lead to inconsistent behavior. IBM provides coexistence support on 2.5, RACF APAR OA67786 provides coexistence support to ensure that containment settings are maintained when updating revocation status and using a shared database.

The core commands:

Containment revolves around five RACF commands you’re already familiar with, just extended with new operands.

• Contain a user immediately

           ALTUSER <userid> CONTAIN

           This instantly blocks access — including ongoing TSO/E sessions, jobs, and server tasks.

• Check a user’s containment status

           LISTUSER <userid>

           Look for the CONTAINED attribute

           Example: User fred is contained:                       

• Display all currently contained IDs (for this IPL)

           SETROPTS LIST

           You’ll see the containment list under the SETROPTS output

• Remove containment and resume the ID

       ALTUSER <userid> NOCONTAIN RESUME

       Both NOCONTAIN and RESUME are needed to fully restore access.

• Mark IDs that must never be contained

          ALTUSER <stcuser> NEVERCONTAIN

         Undo with:

         ALTUSER <stcuser> ALLOWCONTAIN

         Use this sparingly — incorrectly marking IDs as NEVERCONTAIN can prevent you from stopping a malicious process.

IBM recommends considering the NEVERCONTAIN attribute for user IDs (Critical task ids, Critical administrative task ids) that are assigned to servers and critical system services to avoid the impact of incorrectly assigning them the CONTAIN attribute.

Delegating Authority (Without RACF SPECIAL attribute)

One of the best improvements is that you don’t need to give someone SPECIAL to let them use containment. RACF provides a dedicated FACILITY class profile: IRR.CONTAIN.USER.

Access levels map to actions:

• READ → can CONTAIN (via ALTUSER or ADDUSER)
• UPDATE → can CONTAIN, NOCONTAIN, NEVERCONTAIN, ALLOWCONTAIN

This gives your security team precise, auditable authority without excessive privileges.

Monitoring and Audit

RACF provides several ways to track containment events:

• SAF failures include a unique reason code, making it clear that the user is contained.
• SMF 80 (event code 92) records containment actions, perfect for SIEM (Security Information and Event Management) alerting.
• ENF 71 signals are issued when containment state changes useful for exits or subsystems that listen for ENF events.
• The R_admin callable service can also return containment information, making it easy to integrate into scripts or automation.

This gives you strong visibility during incidents and good forensic detail afterward.

Operational Gotchas

Containment is simple to use, but there are a few behavioral quirks worth keeping in mind:

1. The containment list resets every IPL

Containment is stored in memory, so after an IPL, no users remain contained unless you reapply the setting. Contained users remain revoked and unless they are used as STC IDs cannot start new sessions.

2. The list has a hard limit of 100 IDs

If you exceed the limit, additional IDs will be revoked but not contained, meaning they may still run in active sessions. Containment is intended to be used short term and keep a user from operating while an incident is being investigated.  Once the investigation is complete the user should either be unquarantined or deleted based on the outcome.

3. Deleting a contained user doesn’t remove them from the list

This prevents a deleted ID from regaining access through an existing session. If you recreate the ID, you must remove containment at the same time. 

4. “Resume doesn’t work” almost always means “the user is still contained”

If a RESUME fails, check LISTUSER. If the user is CONTAINED, run:

ALTUSER <userid> NOCONTAIN RESUME

Quick Incident Response Runbook

Here’s a simple runbook you can drop into your team’s procedures:

1. Contain immediately

ALTUSER <userid> CONTAIN

Record the time, who executed it, and why.

2. Confirm status

LISTUSER <userid>

Check for CONTAINED.

3. Review impact

Identify systems, tasks, or server processes running under that ID.

4. Monitor

Review SMF 80 records (event 92) and failed SAF calls for additional indicators.

5. Remediate

Reset credentials, rotate keys, review access, and determine next steps.

6. Restore once the user is checked

ALTUSER <userid> NOCONTAIN RESUME

Why Every z/OS Security Team Should Use This

User ID Containment gives RACF a capability that security teams have wanted for years: a safe, immediate way to shut down a user’s access across all active contexts. Instead of scrambling to kill jobs or find sessions, containment stops access right at the SAF layer letting you focus on investigation and recovery.

It’s straightforward, easy to automate, and tightly integrated with RACF’s existing command structure and auditing. If you support incident response, operations, or security on z/OS, this feature deserves a permanent place in your toolkit.