What QSECURITY Actually Controls
QSECURITY governs two separate things that people tend to blur together: whether the operating system enforces object authority at all, and whether it protects its own integrity from programs that try to reach around it. Levels 20 and 30 deal only with the first. Levels 40 and 50 add the second, and that second part is what stops a program from calling unsupported internal interfaces or manipulating pointers to touch objects it was never authorised to see.
This is worth being precise about, because a shop running at level 30 with a beautifully maintained authority model still has no integrity protection. The authority rules are enforced right up until something declines to ask.
The IBM i Security Levels
Levels 40 and 50 both require an IPL to take effect. Plan the change into a maintenance window rather than discovering that at 4pm on a Friday.
| Level | What It Enforces | Our Verdict |
|---|
| 10 | No password required. Signing on with an unknown profile created one automatically. | Gone. IBM removed support at V4R3. You cannot set it, and you would not want to. |
| 20 | Password required to sign on. Every user profile is created with *ALLOBJ special authority by default. | Effectively unusable. Authentication with no object security is not a security model, it is a login screen. |
| 30 | Password required, and object authority is enforced. Users no longer receive *ALLOBJ automatically. | The old default. Real authority enforcement, but the operating system will not defend its own integrity. |
| 40 | Everything in level 30, plus operating system integrity protection. Programs cannot call unsupported interfaces or reach objects directly through pointer manipulation. | The practical minimum, and the shipped default. If you are below this, start here. |
| 50 | Everything in level 40, plus stricter validation of message handling and parameters passed between programs at different states. | The right answer for high-assurance and heavily regulated environments. Test it properly before you enforce it. |
The Level Is a Floor, Not a Program
Here is the part that gets skipped. Fortra's annual State of IBM i Security Study has found for years running that the average audited system is already at level 40, and that those same systems still carry default passwords on powerful profiles, far too many users holding *ALLOBJ, and exit points sitting wide open to FTP and ODBC.
So the level is not the finding. The level is the thing almost everybody already got right, which is exactly what makes it such a poor place to stop. Setting QSECURITY to 40 does not clean up your authority model, does not turn on audit journaling, and does not put a single control in front of a network connection. It sets the floor. What you build on the floor is the actual security program.
Moving Up a Level Without Breaking Production
The risk in raising the level is not the level itself. It is old code. Programs written against unsupported interfaces, or restored from a system where nobody was watching, will fail once integrity protection is enforced. The useful part is that IBM i will tell you which ones in advance, if you ask it to.
Turn On Failure Auditing First
Set QAUDLVL to include *PGMFAIL and *AUTFAIL, then run for a normal business cycle. Those entries are your list of what would break, collected before anything breaks.
Read the Audit Journal, Do Not Assume
Month-end, year-end, and quarterly jobs are the classic surprises. A two-week sample will miss them. Cover a full cycle if you can.
Prove It in Test
Raise the level on a test partition, IPL, and run the same workload. Anything that fails there would have failed in production.
Schedule the IPL
The change is not live until the next IPL. Set the system value, confirm it, and let it take effect in a window you chose.
The System Values That Matter as Much as the Level
QSECURITY gets the attention because it has a number attached to it. Several of its neighbours do more day-to-day work and are quietly left at defaults on a lot of systems.
QPWDLVLPassword level 0 to 3. Levels 2 and 3 allow long, case-sensitive passphrases instead of 10 characters.
QMAXSIGNHow many failed sign-on attempts before the profile or device is disabled.
QINACTITVInactive job timeout. Unattended 5250 sessions are a recurring audit finding.
QLMTSECOFRRestricts where *ALLOBJ and *SERVICE profiles are allowed to sign on.
QCRTAUTDefault public authority for newly created objects. Frequently still sitting at *CHANGE.
QALWOBJRSTControls whether objects with security-sensitive attributes can be restored.
QRETSVRSECWhether server security data, including credentials for other systems, is retained.
QSECURITYThe level itself. Requires an IPL before the change takes effect.
Menu Security Is Not Security
Limiting a user to an initial menu and setting LMTCPB(*YES) feels like a control, and for a long time it behaved like one. When a green screen was the only way onto the machine, the menu really was the boundary.
It is not the boundary now. ODBC, JDBC, FTP, DDM, remote command, and Access Client Solutions all reach the data without ever loading a menu. A user restricted to three options on a green screen can often pull the same files straight into a spreadsheet from their desk. Menu security is a usability feature that we kept describing as a security feature, and the space between those two descriptions is where a lot of shops are still exposed.
Check your level first, because it is quick and the answer is binary. Then treat that answer as the starting line. The exposures that turn up in real assessments live in authority management, exit points, and default passwords, not in the QSECURITY value.