The Eight IBM i Special Authorities
Special authorities sit above the object authority model. Object authority answers whether a given profile may touch a given object, and a special authority can make that question irrelevant. There are eight of them, they are not equally dangerous, and knowing which is which is the difference between an authority review that finds something and one that produces a long list nobody acts on.
The Eight Special Authorities
*ALLOBJ and *SECADM together are effectively unrestricted control of the system and its access rules. Anywhere those two travel as a pair, you are looking at a full administrative grant however the profile is described.
| Special authority | What it grants | Our verdict |
|---|
| *ALLOBJ | Bypasses every object authority check on the system. Read, change, or delete any object. | The one that matters most. Every grant should have a name and a reason attached to it, treated as an exception rather than a default. |
| *SECADM | Create, change, and delete user profiles and administer other users' authority. | Just as serious, and less obvious. *SECADM can manufacture more *ALLOBJ, which makes it a route to everything else. |
| *SERVICE | Access to service tools, including displaying and changing storage directly. | Quietly one of the most dangerous on the list. Service tools reach around the normal authority model rather than through it. |
| *SAVSYS | Save and restore any object regardless of the object authority on it. | Reading your data onto tape is still reading your data. Scope it to backup profiles and nothing else. |
| *JOBCTL | Change, hold, release, and cancel jobs, and manage job and output queues system-wide. | Handed out casually to operations staff more often than any other. It can reach other people's spooled output. |
| *SPLCTL | Unrestricted control of every spooled file and output queue on the system. | Payroll prints somewhere. So do the reports nobody wanted shared. This authority reads all of it, with no object authority to stop it. |
| *AUDIT | Control the system auditing configuration and object auditing attributes. | The authority that can switch off the record of what happened. The list of profiles holding it should be very short and reviewed often. |
| *IOSYSCFG | Change system I/O and communications configuration, including servers and network settings. | Legitimately needed for network and server configuration work. Very rarely needed permanently. |
The Problem With Standing Privilege
Most IBM i shops have a handful of profiles carrying *ALLOBJ, *SECADM, or *SERVICE: QSECOFR itself, a few senior administrators, and usually some forgotten service accounts left over from a migration or an integration project. The failure is rarely that those profiles exist. It is that they stay elevated permanently instead of being elevated for the task that needed it, and that nothing records what was done while they were.
That combination is what turns one compromised credential into an unbounded incident, and it is also what makes the incident impossible to reconstruct afterwards. The audit journal will show you that a powerful profile did something. It will not tell you which human being was driving it, because the profile was shared and permanently available to all of them.
How Special Authority Quietly Accumulates
Nobody decides to give forty profiles *ALLOBJ. It arrives one reasonable decision at a time, which is why authority reviews turn up grants that no current employee can explain. These four sources account for most of what you will find.
Group profiles
Authority granted to a group flows to every member, including members added years later for unrelated reasons. Check supplemental groups too, since a profile can inherit from several at once.
Profiles copied from a template
Creating a new profile by copying an existing one is fast and copies the special authorities with it. One over-privileged template quietly reproduces itself across a department.
The temporary grant nobody revoked
Elevated once to resolve a production problem at an unreasonable hour, never removed, because removing it has no deadline and no owner. This is the single most common finding.
Service and integration accounts
Vendor installers and integration projects frequently ask for *ALLOBJ because it is easier than working out the actual requirement. That profile then runs unattended for years.
What Privileged Access Management Adds
A privileged access management product lets an administrator request temporary elevation to a specific authority or profile, for a defined window, with the request and every action taken while elevated recorded. When the window closes the elevation is revoked automatically rather than depending on somebody remembering to sign off. The permission set does not shrink. The time it exists for does, and so does the ambiguity about who used it.
Standing Privilege vs Managed Elevation
| Standing Privilege | Managed Elevation |
|---|
| Duration of elevated access | Indefinite | Time-boxed and revoked automatically |
| Approval before elevation | None | Request and approval recorded |
| Logging of actions taken | System audit journal only | Session-level activity tied to the elevation request |
| Who approved the access | Not captured | Captured as part of the request record |
| Attribution to a named person | Weak, powerful profiles are usually shared | Direct, the request belongs to an individual |
The Products That Do This on IBM i
This is a small and mature market, which is good news: the products have been doing one job for a long time. Fortra's Powertech Authority Broker is the most widely deployed and the one most IBM i administrators will have met, offering profile swapping and elevation with session-level recording. Raz-Lee's iSecurity Authority on Demand covers the same ground, granting elevation for a defined task and window, and comes up regularly in mid-market European shops. Precisely's Assure Security suite includes an elevated authority component, which is worth weighing if you are already buying that suite for encryption or monitoring and would rather not add another vendor.
Choose on two things rather than the feature list: whether the recording it produces is something your auditors will actually accept, and whether the elevation request flow is light enough that your administrators will use it instead of quietly asking for standing access again. A control that gets bypassed in practice is worse than no control, because it also produces a false sense that the problem was handled.
QSECOFR Is Not a Login
QSECOFR is IBM-supplied, cannot be deleted, and arrives carrying the strongest special authorities on the system. On a lot of machines it is also still a shared account with a password that several people know and that has not changed in a while, which is exactly the arrangement that makes an incident unattributable. Industry assessments keep finding default or weak passwords on QSECOFR and its equivalents, and it stays on the list year after year.
The practical position is that QSECOFR should be an emergency account, not a working one. Administrators get named, individually owned profiles, elevation happens through a managed request, and QSECOFR sits with a strong password, a monitored sign-on, and somewhere sensible to retrieve it from when it is genuinely needed. QLMTSECOFR is worth setting while you are there, so profiles with *ALLOBJ and *SERVICE can only sign on at devices you nominated rather than anywhere on the network.
Adopted Authority as a Lighter-Weight Alternative
For application-level elevation, IBM i's native adopted authority is often the correct answer and costs nothing. A program compiled to run under the authority of its owner rather than its caller gives users exactly the access that program needs, scoped to that program's function, without granting anything to the user's own profile. Used deliberately, it is how you stop needing broad grants in the first place.
Two caveats that matter in practice. Adopted authority is a property of the program, so a badly scoped program becomes a standing grant with extra steps, and reviewing what your programs adopt belongs in the same exercise as reviewing what your profiles hold. And it is not a replacement for managed elevation on interactive administrative work, because a human at a command line is not scoped to one program's function. Use adopted authority for applications, managed elevation for people.
Finding Out What You Actually Have
Every recommendation above depends on knowing the current state, and almost nobody does at the start. This is a half-day exercise that reliably surprises people, so do it before deciding what to buy.
Print the user profile report
PRTUSRPRF gives you special authorities across every profile in one pass. Start here, because it turns an opinion about who has *ALLOBJ into a list you can count.
Run an authority collection
Authority Collection, available from IBM i 7.3, records the authority actually used rather than the authority held. That difference is the evidence you need to revoke a grant without breaking a job.
Follow the group profiles
Resolve what each profile inherits through its group and supplemental groups. Direct grants are the easy half; inherited authority is where the surprises live.
Turn on security auditing
Include *SECURITY in QAUDLVL so authority changes and profile changes are recorded from now on. Without it you can describe today's state but not how it got there.
Implementation Priorities
Inventory before you buy
Find every profile holding *ALLOBJ, *SECADM, or *SERVICE and decide who genuinely needs standing access. The inventory usually shrinks the problem enough to change which product you need.
Start with the highest-risk profiles
QSECOFR and anything holding *SECADM are the highest-value candidates for managed elevation. Start there rather than attempting a full rollout nobody has time to finish.
Send the logs to a SIEM
Forward elevation records to wherever the rest of your security monitoring lives, so privileged activity is reviewed alongside everything else instead of sitting in a journal on the IBM i box.
Re-run the review on a schedule
Authority creeps back. A one-time cleanup becomes a finding again within a year or two, so put the review on a recurring calendar with an owner's name on it.
If you only do one thing after reading this, count the profiles holding *ALLOBJ and check whether QSECOFR is being used as a shared working account. Those two answers tell you how much of this applies to you, and both are available this afternoon without buying anything.