What are the key z/OS security best practices?

What “good” z/OS security looks like in practice

The core idea is not to make z/OS “locked down” in the abstract, but to make access narrowly scoped, reviewable, and recoverable. On mainframe estates, security fails when operational convenience gradually becomes standing privilege, shared IDs, or broad dataset access. Strong practice means every powerful capability has a named owner, a clear business purpose, and a review path that can prove why it still exists.

That is why least privilege is the anchor control. z/OS environments often support critical batch, transaction, and system functions from a small number of highly privileged accounts, so the real objective is to reduce the blast radius of each account and each permission. A practical target is to separate daily administration from emergency elevation, and to make high-risk access both time-bound and visible.

Protecting system datasets is equally important because dataset exposure can turn into system-wide compromise quickly. Security teams should treat high-value libraries, configuration datasets, JCL repositories, and security databases as control points, not just storage objects. If these assets are writable by too many users or processes, the platform can be altered in ways that defeat higher-level policy.

Why RACF review, segregation of duties, and privileged monitoring matter

RACF review is where policy becomes operational. The most common failure is not a single missing rule, but accumulated exceptions, stale profiles, and broad generic access that no one revisits. Reviewing RACF configuration means checking both the intended design and the effective rights that are actually inherited through groups, defaults, and special authorisations.

Separation of duties matters because z/OS operations can concentrate too much power in too few hands. If the same person or function can change security policy, deploy workloads, and approve exceptions, then mistakes and misuse become hard to detect and harder to unwind. Good practice is to keep security administration, system operations, and application ownership distinct enough that no single role can quietly change the whole posture.

Monitoring privileged activity should focus on the actions that matter most, not just on log volume. Administrative commands, security dataset updates, profile changes, and unusual access to sensitive system resources deserve closer attention than routine user activity. For reader guidance on authentication strength and access control design, MFA Guide and Workforce Identity Security Guide provide adjacent control patterns that help reduce account misuse around privileged access.

Patch discipline, recovery, and the controls that are easiest to overlook

z/OS patching and tuning should be handled carefully because availability pressure often tempts teams to defer change, especially on production systems that run core business workloads. The best approach is to treat patching as a controlled change process with rollback planning, validation testing, and explicit sign-off for security-relevant components. Delay is sometimes acceptable, but only when the risk is tracked and the compensating controls are real.

Logging and recovery controls are often the difference between an incident and a durable loss. If audit trails are incomplete, retained for too short a time, or not reviewed after privilege changes, the organisation may miss both malicious activity and accidental damage. Recovery also needs to be tested, not assumed, because the ability to restore a system dataset or security configuration is only valuable if the restore path is known and rehearsed.

Teams also underestimate how quickly “temporary” access becomes permanent on mainframes. Emergency IDs, exception rules, and vendor access can persist long after the original need has passed. That is why periodic review, ownership validation, and clean revocation processes are part of security hygiene, not optional admin work. API Key Management Guide is useful here as a general model for rotating and retiring high-value credentials and access material when lifecycle control matters.

Risk and Threat Considerations

The main security risk on z/OS is privilege concentration. If one account, group, or security profile can alter system datasets, security definitions, or privileged workloads, an error or compromise can propagate across the platform far faster than on a distributed system.

Failure mechanism: Excessive authority, stale RACF entitlements, or weakly controlled administrative access lets a single actor bypass intended separation of duties and change security-relevant state without timely detection.

Impact: The result can be unauthorized workload manipulation, data exposure, weakened auditability, and loss of confidence in the integrity of production processing and recovery.

Practitioner Guidance

What to prioritise: Start with the privileges that can change security state, dataset content, or execution control. Those accounts and profiles determine whether the rest of the control set is meaningful.

What to verify: Confirm that every privileged role has a clear owner, a documented purpose, and a reviewable approval path. If you cannot explain why a high-power entitlement exists, treat it as a remediation candidate rather than a harmless legacy setting.

Decision rule: If an access path can affect production workloads, security definitions, or recovery material, require stronger review and shorter-lived access than for ordinary operational rights.

Practitioner takeaway: z/OS security is strongest when privilege is narrow, exceptional access is visible, and recovery is as disciplined as prevention.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• What is the difference between role-based access and API key governance for NHI security?
• What are the key vCenter Security best practices?
• What are the key Hyper-V Security best practices?