AS/400 and IBM i Security Guide
Start with the controls that decide who can reach the system and what they can do. The six-step security work order below carries that job from the system foundation through detection, identity, and recovery.
Go to the six-step security work orderAS/400 Security Best Practices in Working Order
A long best-practice list can make every gap look equal. It is not. A missing review date matters, but it does not carry the same exposure as a powerful default password or open ODBC access. The sequence below starts with the controls that can change the outcome fastest.
Confirm the security foundation
Check QSECURITY first. Level 40 is the practical floor for modern production work, with level 50 available when application compatibility has been proven.
Remove easy identity failures
Find default passwords, dormant profiles, shared powerful accounts, and profiles nobody can still explain.
Reduce standing authority
Inventory *ALLOBJ, *SECADM, group inheritance, adopted authority, and broad *PUBLIC access before adding another product.
Control every network entrance
FTP, ODBC, JDBC, DDM, and remote command need tested exit-point rules and enforced encrypted transport.
Turn evidence into detection
Configure QAUDJRN for the events that matter, then give a named person useful alerts and a review schedule.
Add stronger identity and data protection
Extend MFA beyond 5250, encrypt the real data copies, and prove that protected backups can still be restored.
The Control Map
Where each security job belongs
| Security job | Native IBM i starting point | What good looks like |
|---|---|---|
| System security | QSECURITY and related system values | A tested level 40 or 50 baseline with documented exceptions |
| Identity | User profiles, password values, group profiles | No default or orphaned powerful profile and no unexplained shared access |
| Authority | Object authority, authorization lists, adopted authority | Access follows job need and broad *PUBLIC authority is tested down |
| Network access | Host servers, DCM, exit-point interfaces | Each active service has an owner, enforced rules, and encrypted transport |
| Detection | QAUDJRN and object journaling | Events are collected, normalized, reviewed, and tied to response |
| Recovery | Save operations, BRMS, storage controls | Protected copies are isolated from production access and restored in a real test |
Best Practices That Hold Up on a Real System
Prove before changing
Use authority collection, current reports, and observed traffic so cleanup does not become an outage.
Separate people from permanent power
Use adopted or temporary authority where possible so a human profile does not carry broad access all day.
Treat the network as the front door
A menu restriction is only a partial control when database drivers and file-transfer services reach the same data.
Give every control an owner
A journal, alert, certificate, exception, or restore plan without a named owner will drift quietly.
Advice That Creates False Comfort
Renaming QSECOFR can slow down a guess, but it does not reduce the authority held by the replacement profile. A limited initial menu can shape a 5250 session, but it does not govern ODBC or FTP. An annual review can document a year of drift without catching it when it happens.
Use those measures only for the small job they actually do. Put structural control around powerful profiles, network services, authority, journal review, and recovery copies instead of asking a cosmetic change to carry the whole system.
You can start without buying anything. The fastest early work is configuration, inventory, ownership, and cleanup. Software earns its place when it provides enforceable exit-point control, MFA, useful audit reporting, encryption management, or continuous monitoring that the native pieces do not deliver alone.
Instant Security Exposure Check
Answer twelve questions and get a visual readiness reading plus the three fixes worth doing first.
Security Levels and System Values
What QSECURITY 20, 30, 40 and 50 enforce, how to move up safely, and the system values left at defaults.
Security Assessment
Work out where the system actually stands before deciding what to change.
Vulnerability Reference
The recurring exposures found across live IBM i systems, not one-off CVEs.
Authority Management
Special authorities, *PUBLIC, and adopted authority in day-to-day control.
Hardening Guide
The tested system value, authority, and exit-point changes that reduce exposure.
Auditing and Logging
QAUDJRN, object journals, security tools, and the review work that turns records into detection.
Multi-Factor Authentication
How MFA attaches to IBM i sign-on and network access, including the routes it can miss.
Encryption
Database, IFS, backup, and network encryption with the key-management questions that matter.
Compliance
SOX, PCI DSS, HIPAA and GDPR mapped onto IBM i controls and evidence.
Security Software
What the product categories do and where commercial tools earn their cost.
Vendors, Evaluated
Real strengths and limitations for each vendor, not a name-only directory.