IBM i Knowledge Base

IBM i Security Basics

IBM i has a strong security reputation built into its object-based architecture, but that reputation has led many organizations to under-invest in configuration. Security levels, user profiles, object authorities, and exit points are the core concepts worth understanding.

IBM i is frequently described as one of the most secure commercial operating systems available, and its object-based architecture gives it real structural advantages. That reputation has a downside: many IBM i environments run with security settings that were adequate in the 1990s and have never been revisited, because the platform "just works" and rarely gets breached in ways that make headlines. This article covers the core concepts administrators and evaluators should know.

System Security Levels (QSECURITY)

IBM i controls its baseline security posture through the QSECURITY system value, with levels ranging from 10 (no security, deprecated and no longer supported on current releases) through 40 and 50, which enforce full object-based integrity protection and are what IBM recommends for production systems. Many long-running IBM i shops are still on QSECURITY 30, which enforces resource security but not the stricter OS integrity protections of level 40 and above. Reviewing the current QSECURITY level, and understanding why it was set that way, is a common first step in an IBM i security assessment.

User Profiles and Special Authorities

Every IBM i user operates under a user profile, which defines what the user can do at the system level through special authorities such as *ALLOBJ (all object access), *SECADM (security administration), and *SAVSYS (save/restore access). A common finding in IBM i security reviews is an excessive number of user profiles holding *ALLOBJ authority, often accumulated over years as a shortcut to avoid troubleshooting access problems. Auditing special authorities against actual job requirements is one of the highest-value, lowest-cost security improvements available on IBM i.

Object-Level Authorities

Beyond user profile authorities, IBM i enforces access at the object level: a specific library, file, or program can have its own authority list independent of what a user's profile otherwise allows. This granularity is a strength of the platform, but it also means object authorities can drift out of sync with actual business need over time, particularly on systems that have changed ownership, developers, or IT management multiple times since the original AS400 deployment.

Exit Points and Network Access

A significant share of modern IBM i security exposure comes not from 5250 terminal access but from network-level access through interfaces like FTP, ODBC, and DDM, which can bypass menu-based application security entirely if left unmonitored. IBM i exit points allow administrators to intercept and control these network access paths, and third-party exit point management software is common in IBM i shops handling regulated data. This is frequently the biggest gap in otherwise well-secured IBM i environments, precisely because it is invisible from the green screen interface most administrators are used to monitoring.

Frequently Asked Questions

Is IBM i secure by default?
IBM i has strong security architecture available, but default and legacy configurations are often less strict than current recommendations. QSECURITY level, user special authorities, and unmonitored network access paths like FTP and ODBC are the most common gaps found in real environments.
What is QSECURITY on IBM i?
QSECURITY is the system value that sets IBM i's baseline security enforcement level. IBM recommends level 40 or 50 for production systems; many long-running environments remain on the less strict level 30.
What is *ALLOBJ authority?
*ALLOBJ is a special authority that grants a user profile access to all objects on the system. It is commonly over-assigned on older IBM i environments and is a standard target of security audits.
Why do IBM i systems get breached despite the platform's reputation?
Most IBM i security incidents trace back to configuration, not the platform itself: over-privileged user profiles, an outdated QSECURITY level, or unmonitored network access paths such as FTP and ODBC that bypass traditional 5250 menu security.