Ask an IBM i admin why the platform hasn't been in a breach headline and you'll usually get some version of the same answer: nobody attacks what they don't understand, and almost nobody outside the shop understands RPG, DB2 for i, or the green-screen menus sitting between an attacker and the data. It's a comforting story, and it isn't entirely wrong — obscurity is a real, if weak, layer of defense. But it has calcified into something closer to a doctrine: the belief that the platform itself is inherently secure, that a QSECOFR profile with a strong password is basically the whole job.
Fortra has been quietly testing that doctrine against real production data for over two decades. Every year the company that owns the PowerTech line of IBM i security tools pulls anonymized configuration data from customer and prospect partitions — password rules, special authorities, exit point coverage, audit settings — and publishes it as the State of IBM i Security Study. It is the closest thing this platform has to an annual physical. The 2026 edition, the 23rd, looked at 163 server partitions. The picture it paints is not of a platform under siege, and not of a platform that's fine either. It's a platform where the security model is genuinely strong and the day-to-day administration of it is, in a meaningful number of shops, not.
That gap matters more now than it did a decade ago. IBM i shops are no longer air-gapped by default — they're connected to VPNs, exposed through modernized web front ends, integrated with cloud middleware, and increasingly targeted specifically because attackers know the security tooling market around this platform is thinner and the administrative attention is, per Fortra's own data, inconsistent. A ransomware operator doesn't need to understand RPG or DB2 for i internals to encrypt an IFS directory or exfiltrate data through a profile with a default password. The obscurity that used to be a real, if incidental, layer of protection erodes a little more every year the platform stays connected and valuable.
A strong lock on a door that's often left open
Start with the number that IBM i partisans reach for first: system security level. IBM i supports five levels, from 10 (essentially no security) to 50 (the level required for the strictest compliance regimes). Level 40 is the effective floor for anything resembling a real security posture, because it's the level at which the operating system starts enforcing integrity controls that prevent programs from directly manipulating system objects.
That's a genuinely good number, and it's the kind of stat that ends up on a slide in a vendor pitch about how IBM i is inherently more secure than Windows or Linux. What that slide leaves out is that level 40 governs how the operating system enforces its own integrity — it says nothing about whether the thousands of user profiles, library authorities, and network entry points sitting on top of that foundation are configured sanely. A locked front door doesn't matter if the side windows are open, and the study's other findings are mostly about the windows.
Default passwords: the fix everyone agrees on and few finish
Default passwords — where a user profile's password is set to match the profile name itself — are the single easiest account compromise on any platform, IBM i included. IBM i even flags them for you: the QSECURITY-aware system commands can list every profile with a default password in seconds. There's no discovery problem here, only a follow-through problem.
The distribution is where it gets uncomfortable. It isn't ten percent of systems with one stray forgotten profile each. Fortra's 2026 data found 49 systems carrying more than 1,000 profiles with default passwords, and one outlier system had over 11,000 user profiles set to default credentials, 80% of which were still enabled. That's not a gap in a checklist. That's a system where, if an attacker can get any kind of network foothold, guessing a valid login is close to trivial for thousands of accounts simultaneously.
“This is something that, without a doubt, is one of the easiest things to remediate.”
Sandy Moore, Principal Solutions Engineer, Fortra
The prior year's study, covering 154 partitions, told the same story from a slightly different angle: 8% of user profiles carried default passwords, 36% of partitions had 30 or more such profiles, and six systems had over 1,000 — one with nearly 4,000. Password strength wasn't much better on the standards side either: only 8% of partitions in 2025 enforced the 12-character minimum required by PCI DSS 4.0, and less than a third used IBM's QPWDRULES system value to set any modern password composition policy at all. This is not a platform limitation. IBM i has supported strong password rules for years. It's an administration gap, and it's the same gap Fortra has been documenting for two decades.
The *ALLOBJ problem: powerful profiles nobody's counting
If default passwords are the easy problem, special authority sprawl is the structural one. *ALLOBJ is IBM i's equivalent of root or Domain Admin — a special authority that grants a user profile access to every object on the system regardless of the object's own authority settings. It's meant for a handful of system administrators. In practice it accretes onto service accounts, onto developers who needed it once for a migration and never had it revoked, onto profiles nobody remembers creating.
By the percentage measure, 2026's data actually showed improvement — 8% of profiles held *ALLOBJ, down from 11% the year before. That's real movement, and it's worth crediting. But percentages flatten scale, and *ALLOBJ isn't the only special authority worth worrying about. *JOBCTL grants control over jobs, subsystems, and output queues system-wide; in the wrong hands, or the wrong malware's hands, it's a way to halt or redirect production work. *SAVSYS grants the ability to save and restore any object on the system, which means it can also be used to exfiltrate a complete copy of it.
- Average of 889 users held *JOBCTL authority per system in 2026 — a significant increase over the prior year's average.
- Average of 649 users held *SAVSYS authority per system in 2026, also a notable increase.
- 8% of users held *ALLOBJ authority in 2026, down from 11% in 2025 — one of the study's clearer improvements.
- 68% of systems in the 2025 study had at least one "unsecured" profile — a profile with a blank or trivially bypassed password prompt — and 12% had ten or more, both increases over 2024.
“*JOBCTL can end your system. It shouldn't just be handed out to everybody.”
Amy Williams, Principal Security Services Consultant, Fortra
The 2025 data adds another layer to this: 30% of libraries on the average partition allowed *PUBLIC read access, 43% permitted *PUBLIC changes, and only 16% were set to *EXCLUDE, the setting that forces an explicit authority check rather than defaulting open. That's the object-level authority model — the thing IBM i's architecture actually gets right at a technical level — being routinely configured in the least restrictive way it supports. The capability is there. The discipline to use it isn't consistently there.
Exit points: the network doors people forget are doors
Object-level authority governs what happens once someone is on the system. Exit points govern how they get network access to system functions in the first place — FTP, ODBC, DDM, remote command execution, and roughly two dozen other server functions each have an associated exit point where a program can intercept, log, or reject a connection attempt before it ever reaches the underlying function. Without an exit program registered at those points, IBM i's object-level authority is often the only thing standing between a network request and the data, and depending on how that authority is configured — see above — that may not be much.
That two-year trend line — 58% to 73% with at least one exit program, and full 27-point coverage climbing from 7% to 28% to 31% over the equivalent stretch of studies — is one of the more genuinely encouraging signals in the whole data set. It suggests IBM i shops are, at minimum, aware that FTP and ODBC access without any logging or filtering is a real gap, not a theoretical one. It also means that as recently as the most current study, roughly seven in ten systems still had at least one of those 27 network doors sitting unmonitored.
What's actually getting better, and what isn't
It would be inaccurate to write this up as pure decline, and Fortra's own framing doesn't support that reading either. Audit journal adoption — the QAUDJRN configuration that gives you a forensic record of security-relevant events after the fact — sat at 96% of systems in 2026, up from 94% in 2025 and 81% back in 2023. That's a real, sustained improvement, and it matters: an audit trail is what turns "we think something happened" into "here's exactly what happened, when, and as whom."
“It is absolutely the tool used in a forensic analysis.”
Amy Williams, Principal Security Services Consultant, Fortra, on the audit journal
Other lines move the wrong direction in the same report. Virus scanning on file open — a baseline control against ransomware payloads landing in the IFS — dropped to 54% of systems in 2026 from 62% the year before, and the researchers noted a recurring configuration gap where scanning is technically enabled but no actual antivirus engine is registered to do the scanning, meaning the switch is flipped and nothing is behind it. Password minimum length compliance with PCI DSS 4.0's 12-character standard did improve, from 8% to 32%, but that still leaves roughly two-thirds of systems below a standard most of them are nominally required to meet if they touch payment data at all.
The people who run this study every year have started to sound less like researchers and more like people watching the same rerun.
“We have been doing this for over 20 years, and sometimes I feel like we're having the same conversation every year.”
Sandy Moore, Principal Solutions Engineer, Fortra
So is IBM i actually secure?
The honest answer is that the platform and the deployment are two different questions, and the reputation only answers the first one. IBM i's security architecture — object-level authority as a system-wide default, integrity enforcement at level 40 and above, exit points as a chokepoint for network access, an audit journal that can't be selectively disabled by an unprivileged process — is genuinely well designed, arguably ahead of what ships by default on more commonly attacked platforms. That part of the reputation is earned.
What the reputation glosses over is that a well-designed security model run with default passwords, *ALLOBJ handed out like a parking pass, and a third of network exit points unmonitored is not a secure system — it's a secure system's blueprint sitting next to an unlocked filing cabinet. Twenty-three years of the same study finding the same categories of gap, some improving and some not, is strong evidence that the risk here was never really about the platform being fundamentally exposed. It's about IBM i's low attack profile buying shops years of runway to fix this stuff, and a lot of shops spending that runway on other priorities instead. The systems in this study aren't hypothetical — they're production partitions running payroll, claims, and order entry at companies that would tell you, if you asked, that IBM i is the platform nobody hacks. They're just not all backing that claim up in their own configuration.
For anyone maintaining RPG applications on top of one of these systems, the practical takeaway isn't abstract. It's worth knowing what QSECURITY level your partition actually runs at, whether the service accounts your programs run under carry *ALLOBJ or *JOBCTL they don't need, and whether the libraries your applications write to are sitting on *PUBLIC *CHANGE by default. None of that requires a security specialist to check — DSPUSRPRF and DSPOBJAUT will tell you in minutes. The study's real lesson isn't that IBM i is insecure. It's that the platform hands you a strong security model and then gets out of the way, and "getting out of the way" is exactly how default passwords survive for twenty-three consecutive years of the same annual report saying, in effect, please turn these off.
Browse the RPG reference →Compare IBM i security and monitoring vendors →