Common mistakes are overprivileged users, weak control of privileged utilities, and inconsistent review of RACF and subsystem permissions. Practitioners should separate duties, restrict sensitive datasets and commands, review started tasks and batch identities, monitor audit records, and ensure system exits, exits datasets, and configuration changes are tightly governed.
Where z/OS security reviews most often go wrong
The most common failure mode is treating z/OS security as a one-time access setup rather than a living control environment. Overprivileged users, broad dataset access, and permissive subsystem permissions create silent exposure, especially when day-to-day operations depend on a small set of trusted accounts. Review is strongest when it is routine, scoped by business need, and tied to actual system usage rather than inherited assumptions.
A second mistake is letting powerful administrative utilities and batch identities become de facto exception paths. On z/OS, those paths can bypass ordinary application controls if they are not separately constrained, logged, and periodically revalidated. That is why controls around started tasks, batch submissions, and sensitive command use matter as much as user sign-on policy.
A third recurring issue is inconsistent governance of configuration changes, system exits, and exit datasets. These components can materially alter enforcement behavior, so weak change control can turn a stable security design into a loose collection of exceptions. The Top 10 Cloud Security Risks resource is useful here because the same pattern appears wherever privilege and configuration drift outrun review discipline.
How privilege and permissions drift create z/OS exposure
z/OS security errors usually accumulate through permission creep, not dramatic single events. RACF and subsystem rules become inconsistent when teams grant access for a short-term need and never revisit whether the user, started task, or batch identity still requires it. That produces excess trust in datasets, commands, and administrative functions that are difficult to monitor after the fact.
Privileged utilities are another pressure point because they often sit outside normal application authorization paths. If those tools are reachable by too many operators, the environment can shift from controlled administration to broad system alteration. Strong review should therefore focus on who can run what, under which account, and with what observable trace.
Legacy operational shortcuts are a common root cause. When teams depend on shared IDs, broad generic permissions, or exempted controls to keep processing moving, they can preserve availability while undermining accountability. The Top 10 Endpoint Security Risks page reinforces the same lesson in another environment: local privilege and credential concentration turn convenience into risk if they are not bounded and reviewed.
What to tighten first in a z/OS review
Start with the identities that can change the system, not the ones that merely use it. Started tasks, batch identities, operators, and accounts with access to sensitive datasets or commands deserve the strictest review because they combine reach with low friction. Separate duties so routine processing, security administration, and system maintenance do not sit in the same trust bucket.
Then verify that audit records are not only enabled, but actually used to detect misuse patterns. Review for unusual command execution, unexpected dataset access, and changes to exits or security-relevant configuration. A control is weak if it exists on paper but nobody can explain how it would surface abuse in time to matter.
Finally, treat changes to exits, exit datasets, and subsystem definitions as high-sensitivity events. These are not ordinary configuration updates, they are enforcement changes. The NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference point for this kind of review because it ties access control, auditing, and configuration management together in a way that maps cleanly to mainframe operations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Overprivileged users and utilities are central to this z/OS security question. |
| AU-6 — Audit Record Review, Analysis, and Reporting | The answer stresses monitoring audit records for misuse and drift. | |
| CM-6 — Configuration Settings | Exit datasets and security-relevant configuration changes need tight governance. | |
| Recommendation — Limit administrative and dataset access to the minimum required for each role. Review audit records for unusual access, command use, and security changes. Restrict and review security-relevant configuration changes under change control. | ||
Practitioner Guidance
What to verify: Confirm that privileged access is tied to named administrative need, not inherited through group membership, shared accounts, or historical exceptions. If a user, batch identity, or started task can touch production data or execute sensitive commands, its permissions should be justifiable from current operations, not from legacy practice.
What changes at scale: As the number of systems, jobs, and operators grows, manual review becomes less reliable unless it is narrowly targeted. The practical test is whether you can still distinguish routine access from exceptional access quickly enough to act on it before a weak permission becomes normal behavior.
Common mistake: Teams often harden user sign-on while leaving subsystem permissions, exits, and operational utilities under-reviewed. That creates a false sense of control because the visible access path looks better while the more powerful pathways remain open.
Practitioner takeaway: z/OS security failures are usually governance failures disguised as technical ones, so the priority is to reduce privilege sprawl, make powerful paths visible, and keep configuration authority under continuous review.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org