What are the key AS/400 security best practices?

Which AS/400 controls matter first?

The core security work on an AS/400, now commonly referred to as IBM i, is about controlling who can do what, where those privileges come from, and how much standing access remains in place after the original need has passed. That means limiting user and operator authority, reviewing profiles, separating duties, and treating old inherited rights as risk until they are proven necessary.

Because IBM i systems often outlive multiple administrative eras, the security baseline is frequently shaped by history more than intent. That makes profile review and authority cleanup more important than a one-time hardening exercise, especially where inherited menus, shared operator accounts, or broad special authorities have accumulated over time.

Remote administration deserves the same scrutiny as local access because it is often the easiest path to elevated control. Secure the administrative channel, restrict who can use it, and align every administrative path with a named owner and a business reason so that convenience does not become unreviewed privilege.

How should access and object changes be governed?

On IBM i, the most useful mental model is that authority to the system is not just about sign-on. Access to critical objects, system values, command execution, and configuration state all need review because a user with the wrong combination of rights can alter security controls without ever appearing to be a traditional administrator.

Monitor changes to critical objects and system settings with the same seriousness you would apply to privileged account activity. The practical goal is not only detection after the fact, but also the ability to explain who changed what, when, and under which authority, so that a review can distinguish sanctioned administration from unauthorized drift.

Clear separation of duties helps because IBM i environments often concentrate operational power in a small number of profiles. When the same person can approve, administer, and modify security-related objects, a mistake or misuse can bypass the normal friction that would otherwise expose the change.

What makes legacy IBM i security drift dangerous?

Legacy AS/400 environments often retain permissions that were granted for old workflows, temporary projects, or previous staff and never fully removed. That creates a quiet accumulation of excess access, where the system looks stable but the actual authority model is broader than the organisation believes.

Security drift is dangerous because it undermines both prevention and investigation. If profile authority is overextended, then an apparently minor account compromise can become a direct path to sensitive files, application data, or system settings; if review records are thin, it becomes harder to prove whether a change was legitimate.

Historical permissions also matter because they can survive application changes. A profile may no longer need production access, but it may still carry inherited object authority or operator-style privileges that were never re-evaluated when the business process moved on.

Risk and Threat Considerations

AS/400 security risk usually comes from standing privilege, shared administrative responsibility, and weak visibility into profile and object changes. Those conditions make accidental misuse easier and give an attacker or insider a reliable path to expand access once they obtain any foothold.

Failure mechanism: Excess authority or stale inherited permissions let a compromised or overtrusted profile modify critical objects, alter security settings, or access data beyond its intended scope, while poor change monitoring delays detection.

Impact: The result can be unauthorized data exposure, tampering with system controls, persistence through trusted accounts, and a much larger blast radius than the original access level should allow.

Practitioner Guidance

What to prioritise: Start with the profiles that can change security-relevant objects, run commands with elevated authority, or administer remotely. Those accounts create the fastest route from ordinary access to system-wide impact, so they deserve the first review cycle.

What to verify: Confirm that every privileged profile has a current owner, a documented purpose, and a reviewed reason for each special authority. Then verify that critical object changes are logged in a way that is usable for investigation, not just retained for compliance.

Common mistake: Treating IBM i as “stable” and therefore low risk is a frequent error. Stability often hides accumulated privilege, and long-lived platforms are especially prone to access paths that are no longer justified but still fully active.

Practitioner takeaway: The strongest IBM i security posture comes from reducing standing privilege, continuously re-validating access, and making high-impact changes observable enough to challenge both mistakes and misuse.

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?