IBM i Security Levels and Security Best Practices Explained
What QSECURITY levels actually control, why level 40 is not automatically enough, and how audit journaling and SIEM integration fit into an IBM i security program.
QSECURITY is the floor, not the whole program
IBM i security starts with the QSECURITY system value, which controls how strictly the operating system enforces access and integrity. According to IBM's own documentation, level 20 requires a user ID and password but still grants broad default access, level 30 requires specific authority to use resources, and level 40, the level systems ship at, adds integrity protection between system and user state programs. Level 50 adds the strictest integrity enforcement and is the level required for C2, FIPS-140, and Common Criteria certification.
IBM's guidance is direct about the floor: the minimum recommended level is 30, with 40 or higher preferred for most organizations. But QSECURITY is a platform-wide setting, not a substitute for object-level authority design. A system at level 50 with poorly managed user profiles and *ALLOBJ authority handed out liberally is still exposed. Buyers evaluating security software should treat the current QSECURITY level as context for the conversation, not as evidence the environment is already secure.
Object authority and profile hygiene do the daily work
Once the security level is set, the harder and more continuous work is authority management: who has *ALLOBJ, *SECADM, or *SPLCTL special authorities, which service accounts exist and why, and how quickly access is revoked when someone changes roles or leaves. This is where most audit findings actually originate, because special authorities tend to accumulate over years without a formal review process.
Security and MFA vendors typically start an engagement by inventorying special authorities and stale profiles before recommending any new tooling, since a strong authentication layer sitting on top of overly broad object access does not close the underlying gap.
- Review who holds *ALLOBJ, *SECADM, and *SPLCTL authorities and why
- Identify service accounts and confirm they cannot be used interactively without justification
- Set a recurring cadence for profile and authority review, not a one-time cleanup
Audit journaling and SIEM integration close the visibility gap
IBM i has built-in audit journaling (QAUDJRN) that can capture object access, authority changes, and system events, but that data stays local unless something forwards it. Getting IBM i visibility into a centralized security platform typically means routing audit journal entries and message queue data like QHST through a log forwarding tool into a SIEM such as IBM QRadar or Splunk, usually in syslog, CEF, or LEEF format.
This step matters because IBM i activity is frequently the blind spot in an otherwise mature security operations program. A security team watching network and endpoint activity in real time but reviewing IBM i logs manually, or not at all, has a real gap regardless of how strong the perimeter tooling looks.
- Confirm QAUDJRN is active and capturing the event types compliance requires
- Decide whether log forwarding should run in near real time or on a scheduled batch
- Verify IBM i events actually appear and correlate correctly inside the SIEM, not just that a feed exists
Sequence the work instead of trying to fix everything at once
The strongest IBM i security improvements move in a deliberate order: confirm the security level and platform baseline first, clean up authority and profile sprawl second, then extend visibility into a SIEM and add MFA where it is genuinely needed. Teams that reverse this order, for example adding MFA before addressing broad object authorities, often end up with a stronger front door on a house that still has unlocked interior rooms.