IBM i security works by enforcing user profiles, object authorities, system values and auditing around applications and data. It controls what users can sign on to, which objects they can use, and which commands or functions they may run. Administrators should review special authorities, adopted authority and audit journal records.
How IBM i security is structured
IBM i security is built around a centralized operating system model, not a collection of separate application silos. The platform ties identity, access, object protection and auditability together so that access decisions are enforced by the system itself. That makes the security model predictable: if an action is not allowed by profile, authority, or system policy, the operating system blocks it before the application can rely on it.
At the core are user profiles and object authorities. A user profile establishes who can sign on, while object authority determines what that profile can do with programs, files, commands, menus, and other system objects. That distinction matters because IBM i security is not just about logging in, it is about controlling the use of data and code at the object level.
System values shape the baseline rules for the whole partition. They govern behaviours such as password policy, sign-on limits, default security posture, and how tightly the system handles operational tasks. IBM i administrators use those values to set the security floor, then refine access with authorities and profile attributes rather than relying on ad hoc controls inside each application.
Why special authorities and adopted authority matter
IBM i uses special authorities to grant powerful administrative capabilities without giving broad blanket access to everything. This is why reviewing those authorities is a regular security task: a profile with elevated system powers can bypass normal object protections, so the practical risk is not just data exposure but also unintended administration of the environment.
Adopted authority is another important mechanism because it lets a program run with the authority of its owner rather than the caller. That is useful for business functions that need controlled elevation, but it also means the security question is not only who starts the job, it is what authority the program can inherit while it is running. That is one reason IBM i teams should review programs that adopt authority and ensure the business need is still justified.
The platform also distinguishes between direct user authority and authority exercised indirectly through application code. On a well-managed IBM i system, that separation helps preserve least privilege while still allowing legacy or shared applications to function. In practice, security teams should treat adopted authority as an exception path that needs ownership, documentation, and periodic review.
How auditing and command control turn access into evidence
Auditing is what turns IBM i security from a pure prevention model into one that can be investigated and governed. Audit journal records show who did what, when, and through which object or function path, which is essential for detecting misuse, validating administrative actions, and reconstructing incidents after the fact. The operating model is stronger when audit settings are chosen intentionally instead of left at defaults.
Command and function control is part of the same picture. IBM i can restrict what commands or functions a user may run, which helps prevent users from reaching administrative tools or altering security settings outside their role. In NIST SP 800-53 Rev 5 Security and Privacy Controls, the same pattern appears in access control and audit controls: define privilege narrowly, then preserve records that let you verify whether that privilege was used correctly.
For practitioners, the important point is that auditing is not a substitute for authority design. If profiles are overpowered, or if adopted authority is too broad, the audit trail will only tell you that excessive access was exercised. Good IBM i security therefore depends on both prevention and evidence, with one reinforcing the other.
Risk and Threat Considerations
IBM i security fails when powerful profiles, adopted authority, or weak system values create a larger blast radius than the business expects. The most common exposure is privilege misuse, where a legitimate account or program can reach data and functions that were never meant to be broadly available.
Failure mechanism: Excessive special authority, overpermissive object ownership, or poorly governed adopted authority allows a caller or program to bypass the intended access path and operate with higher privilege than the business role requires.
Impact: An attacker or insider who reaches one privileged profile or one trusted application path can alter data, execute administrative actions, or suppress evidence in ways that are hard to distinguish from normal 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-2 — Account Management | IBM i user profiles require disciplined account lifecycle and access assignment. |
| AC-6 — Least Privilege | Special authorities and adopted authority create privilege that must stay tightly bounded. | |
| AU-2 — Event Logging | IBM i audit journals are central to proving and investigating security-relevant activity. | |
| Recommendation — Review IBM i profiles regularly and remove or disable accounts that no longer need access. Limit special authorities and adopted authority to the minimum required for each role or program. Log the IBM i events needed to reconstruct sign-on, object use, and administrative activity. | ||
Practitioner Guidance
What to verify: Confirm which user profiles can sign on, which objects they can use, and whether any programs carry adopted authority that changes the effective privilege model. Review the security value of each exception path rather than assuming it is still needed.
What to prioritise: Start with profiles that hold special authorities, batch or service accounts that touch sensitive data, and programs that can execute with elevated authority. Those are the places where a small configuration mistake has the biggest security consequence.
Decision rule: If a profile or program can reach production data without a clearly documented business reason, treat that as an access design issue first and an audit issue second. If the control only records the activity, it is not enough on its own.
Practitioner takeaway: IBM i security works best when authority is intentionally narrow, elevated access is explicit, and audit records are used to confirm that the operating model you intended is the one actually running.
Related resources from NHI Mgmt Group
- How should security teams decide whether JIT access is safe for non-human identities?
- How should organizations prioritize security in their MCP implementations?
- How should security teams split identity governance from implementation work?
- When should organisations prioritise NHI security over other identity work?