IBM i System Hardening Guide
Hardening is the set of changes you make once assessment tells you where the exposure actually is. This is the priority order we recommend working through.
Tier 1: Immediate, Low-Risk Changes
These changes carry minimal risk of breaking existing functionality and should be near the top of any hardening effort: enforce password expiration and complexity (QPWDEXPITV, QPWDRULES), set QMAXSIGN to lock out accounts after a reasonable number of failed sign-on attempts, force a password change on any powerful profile still holding a default or long-unchanged password, and confirm QALWOBJRST is not set to *ALL.
Tier 2: Requires Testing, High Value
These changes reduce real exposure but can affect existing applications or integrations, so they belong in a test environment first: tightening *PUBLIC authority on production libraries and files, registering exit-point programs on FTP/ODBC/DDM/remote command servers, and raising QSECURITY level if the system is still running below level 40.
Hardening Priority Matrix
| Change | Risk of Breaking Something | Security Value |
|---|---|---|
| Enforce password policy (QPWDEXPITV, QPWDRULES) | Low | High |
| Set QMAXSIGN / QMAXSGNACN | Low | High |
| Force password change on powerful profiles | Low | Critical |
| Restrict QALWOBJRST from *ALL | Low to Moderate | High |
| Tighten *PUBLIC authority on production libraries | Moderate to High | High |
| Register exit-point programs (FTP, ODBC, DDM) | Moderate | High |
| Raise QSECURITY level (30 to 40 or higher) | Moderate | Moderate |
| Deploy MFA on 5250 and network exit points | Moderate (rollout effort) | Critical |
Tier 3: Ongoing Discipline
Hardening is not a one-time project. Recurring authority reviews, periodic re-running of authority collections, reviewing QAUDJRN output on a schedule, and re-checking exit-point rules against new integrations are what keeps a hardened system hardened as applications and staff change over time.
Test every Tier 2 change in a non-production environment against real application traffic before enforcing it in production. Tightening *PUBLIC authority or enabling exit-point restrictions is the single most common cause of a self-inflicted outage during a hardening project when skipped.