An IBM i environment that has never been breached is not the same as one that cannot be breached. That distinction matters more in 2026 than it did two years ago.
The tools attackers use to find open doors have changed faster than most mid-market shops have updated their defenses. IBM i security gaps on unsupported OS versions now represent a structural exposure, not just a configuration risk.
AI-assisted scanning now targets IBM i environments running unsupported OS versions that cannot receive the latest security patches. Shops on V7.3 or older face a structural vulnerability gap that awareness alone cannot close. Current patching, tested backups, and a documented restore process are the baseline defenses every IBM i shop needs right now.
AI-Assisted Scans Changed IBM i Security Overnight
Cybercriminals now use artificial intelligence to automate vulnerability scanning at a scale that was not practical even two years ago. What once required a skilled attacker spending hours probing a single target now executes across thousands of targets simultaneously.
AI-assisted tools can help attackers automate reconnaissance, identify potentially vulnerable services, and prioritize systems with known weaknesses. AI can also generate convincing phishing emails and social engineering schemes that previously required human operators.
One area requiring attention is the IBM i HTTP services and associated open-source components used by some environments. Recent IBM security fixes address vulnerabilities in specific components, but patch applicability depends on the IBM i release and affected software.
Attackers Look for Vulnerabilities, Not Company Size
AI-assisted scanning does not distinguish between a Fortune 500 manufacturer and a 40-person distribution shop. These tools are simply looking for open doors. An unpatched HTTP vulnerability on a V5 or V6 environment registers as an opportunity regardless of the company's revenue or headcount.
I'd estimate that at least 60 percent of IBM i environments in small to mid-market shops run on custom software written and refined over decades. That longevity creates a challenge when the underlying operating system, hardware, or application dependencies need modernization.
Many of these operators do not see themselves as significant enough for cybercriminals to target. The business is small, the system is old, and the assumption is that sophisticated attackers focus on larger organizations.
With AI-automated scanning, that assumption is even less reliable than it was a few years ago. The cybercriminals aren't necessarily selecting targets. They use automated tools to search for vulnerabilities and take the opportunities that appear.
Understanding NIST's framework for vulnerability management reinforces exactly this point. Exposure is not just about what attackers do, but about what conditions organizations have already allowed to exist.
Even Experienced IBM i Practitioners Can Get Caught
Bob Losey has operated in IBM midrange systems since 1979. He regularly contributes to IT Jungle and has served as both President and Treasurer of ASCDI, the Association of Service and Computer Dealers International.
His field experience across thousands of client environments shapes how he interprets threats others often dismiss.
"Cyber criminals are now using artificial intelligence to automate scanning for vulnerabilities and write hyper-realistic phishing emails. I got caught myself. Thank goodness it was from a company I haven't really talked to in a long time, using credentials I no longer use. I would like to think I'm more knowledgeable than a lot of people who encounter phishing scams. But I was caught." – Bob Losey, Founder and President, Source Data Products
The lesson is not simply that even experienced practitioners need to be careful. The sophistication of the lure has increased to the point where awareness alone is no longer adequate defense. Structural protection, starting with current OS patching, has to carry more of the load.
The Backup Problem Nobody Discusses Until It Is Too Late
Current patching is the first line of defense. It is also the one most consistently deprioritized. This stems from a predictable issue I see among small teams: institutional knowledge erodes without anyone noticing.
A recent client is an example of how this erosion occurs. They had been running their backup process like clockwork for four to five years. But when the team went to restore from those backups, every tape was blank.
The original person who set up the backup process had left. The person who replaced them learned the fundamentals, then also left. By the time the business owner was running the backup routine, the verification step had been dropped from institutional memory. Nobody had tested a restore, and nobody knew the tapes were empty until they were needed.
For shops in that position, staying current on patches matters even more. If there is the potential that some institutional knowledge has left, backup recovery might not be as reliable as you think. An unpatched system combined with untested backups is a position no IBM i shop should accept.
The correct path forward is to schedule a restore test as soon as possible. Pull a backup from the prior week and verify it recovers. Then document the steps so the next person in the chair inherits the knowledge rather than the gap.
Source Data's Cloud400 Online Backup service includes automated verification that closes exactly this gap for hosted environments.
The IBM i Security Controls Auditors Expect to See
For compliance-focused organizations, the stakes extend beyond avoiding a breach. The CISA Known Exploited Vulnerabilities catalog increasingly informs what auditors and cyber insurers treat as a baseline expectation.
Running an OS version outside IBM's support boundary, with no patch path for documented HTTP vulnerabilities, is difficult to defend in a controls review. The conversation shifts from "what is the risk" to "why was this not addressed."
IBM i environments running unsupported OS versions face both an operational security gap and a compliance documentation gap. Addressing the OS currency question is not just a technical task. It is the answer to an audit question that is already being asked.
Our post about the IBM i V7.4 end-of-support transition covers this territory in detail. Organizations that completed that upgrade before the support cutoff have a defensible control posture. Those that did not are now managing both the technical exposure and the documentation burden simultaneously.
Common Questions About AI and IBM i Security Gaps
Which IBM i OS versions are currently receiving security patches?
IBM actively issues security patches for V7.4, V7.5, and newer supported releases. Environments running V7.3 or older fall outside IBM's current support boundary and do not receive patch coverage. That includes the recent batch of open-source HTTP security fixes. Verify your OS version across all LPARs before assuming coverage applies.
Why is open-source HTTP a priority IBM i vulnerability right now?
IBM released one of its largest recent security patch batches specifically to address vulnerabilities in the HTTP layer. Attackers using AI-automated scanning tools are actively probing this surface. Shops on unsupported OS versions cannot apply these patches and have no vendor-supplied remediation path.
How does AI change the threat level for small IBM i shops?
AI-automated scanning allows attackers to probe thousands of targets simultaneously without human operators. It does not filter by company size or revenue. A small distribution shop running an unpatched OS version presents the same exploitable surface as a large enterprise. The assumption that small shops are below the radar no longer holds.
How do I verify whether my IBM i backups are actually recoverable?
Pull a backup from the prior week and attempt a full restore in a test environment. Document every step. If the restore fails or the data is missing, address the gap before it becomes critical. Backup verification should be a scheduled recurring task, not a one-time check. We covered the full pattern in a recent post about IBM i backup failures and the importance of verification.
What should I do if my IBM i is running on an unsupported OS version?
Confirm the current OS version across all LPARs. If any environment is on V7.3 or older, begin planning an OS upgrade to a supported version. Patches are only available to clients with active software support coverage, so verify that Software Maintenance Agreement (SWMA) coverage is current before initiating the upgrade. Deferring this decision extends the exposure window. We covered this in more detail in our recent post about how older OS versions don't get critical patches.
Can phishing attacks compromise an IBM i environment?
Yes. Phishing attacks typically target the human layer, not the system directly. Credentials obtained through a successful phishing attempt can grant access to connected IBM i environments, administrative interfaces, or network infrastructure that touches the system. Current OS patches reduce automated scanning risk but do not eliminate the credential-theft vector.
What is the compliance risk of running an IBM i on an unsupported OS version?
Auditors and cyber insurers increasingly reference the CISA Known Exploited Vulnerabilities catalog when evaluating controls. Running an OS version outside IBM's support boundary is difficult to defend in a formal controls review. The documentation burden compounds the technical risk.
Start the IBM i Security Conversation Before an Incident Forces It
The tools attackers use to find vulnerabilities are becoming faster and more accessible. IBM i organizations cannot assume that an older system will remain unnoticed simply because it has operated without an incident. Current patches, tested backups, and documented recovery procedures are essential to reducing that exposure.
Source Data helps IBM i organizations understand where their environments are vulnerable and what steps make sense next. Our team can assess OS currency, security configurations, backup processes, and upgrade readiness. Reach out now to discuss a security assessment before an incident forces the issue.
