Ransomware operators and AI-powered scanning tools do not screen targets by revenue. They're searching for vulnerabilities. A small IBM i shop running an unsupported operating system version is not invisible to those scans. It is simply a target that has not been hit yet.
Small IBM i environments running unsupported OS versions face the same automated threats as enterprise shops, without IBM's security patches to protect them. Security level 20 user profiles, unverified backups, and outsourced code with no security scope are the most common exposures. An assessment before something fails is always cheaper than remediation after.
Thinking You're Too Small to Target Is the Most Dangerous Assumption in IT
There's an assumption that runs quietly through hundreds of small IBM i shops. They operate on the idea that the big attacks happen to big companies. If you just keep things running and stay under the radar, attackers won't notice you.
Most cyber criminals using AI today are not selecting specific targets. They run automated scans across the internet, find systems with known vulnerabilities in open-source HTTP configurations and outdated OS versions, and exploit them at scale.
Being small does not make you invisible. It makes you easier to overlook until something breaks, and by then the window to act has already closed.
IBM recently released one of its largest batches of security patches in recent memory, specifically to address open-source HTTP vulnerabilities. Those patches are available for clients running V7.5 and V7.6. For shops still running unsupported versions, those patches do not exist.
Many IBM i environments running today operate on hardware introduced from the 1990s and roughly 2010, on operating system versions IBM stopped supporting years ago. The people running those environments often do not recognize the threat because there has not been an incident. While they might feel safe, they've really just been lucky.
What a Wildfire Teaches You About IBM i Security Risk
Bob Losey has spent more than four decades working with IBM midrange clients through hardware transitions, security reviews, and OS upgrades. He grounds IBM i security risk in situations that most consultants never encounter. A simple analogy makes the nature of these threats easier to understand.
"In this community, they had eucalyptus trees. So when the fire started to hit the eucalyptus trees, they go up immediately into flames because they're very dry. And those embers can get pulled into the attic. Goodbye house. Sometimes until you see a calamity, you don't know how to protect yourself. IBM has had one of its largest availability of software patches to help users deal with open-source HTTP, which is where the vulnerabilities are. If you're using an older version, they can't help you." – Bob Losey, Founder and President, Source Data Products
A house with a clay tile roof survives most fires. Plant eucalyptus trees nearby and the embers can find a way in. Running an unsupported OS version is like having that eucalyptus tree near your house. It's not inherently dangerous on a calm day, but it's catastrophic when the fire arrives.
Agile Development Teams Create IBM i Security Gaps They Never Intended
A second layer affects shops that have brought in outside programming teams or have run agile-style development over the years.
Agile teams, by design, work in small focused groups with a single mission: build something that works for a specific function. Security architecture is not always on the sprint checklist.
That is not the organization or team being careless. Anticipating every security implication across an integrated IBM i environment is a different discipline, and most agile engagements do not scope for it. The result is software that runs correctly but leaves openings for a credential-harvesting phishing email or an AI-automated scanning tool.
Bob Losey has advised clients through environments dating back to the earliest days of RPG programming. When a security exposure has been quietly building for years, the pattern is easy to recognize.
"I have a client, wonderful company, about 800 users. Their software was developed in the late 70s to mid-80s. All of their users are on security level 20. Now, do they have issues of people coming in? No, not really. However, what they have done is, over the years, as they've added new users, they replicate that profile with security level 20. So they have this huge population of inactive users on that old format. They're getting ready to go to V7.6. If you upgrade and now you have a user at security level 20 and you want to bring them on board, you're going to bring them up to security level 30 or 40 or a higher level. You can't go back." – Bob Losey, Founder and President, Source Data Products
If you're approaching an OS upgrade and have not audited your user profile security levels, talk to Source Data's team before scheduling the migration window.
The Backup You Think You Have May Not Exist
One more detail belongs in this conversation, not to alarm, but because it surfaces more often than most IT leaders expect.
We worked with a client who believed for four to five years that backups were running successfully. When the team went to verify, every tape was blank. A slow handoff through two or three generations of staff had passed along the muscle memory of starting the backup. Nobody passed along how to verify it completed. The person who inherited the responsibility was never trained to check the confirmation.
This is a common story we see when it comes to knowledge transfer. It plays out in small to midsize shops because the institutional knowledge that kept these environments healthy was built by people who have since retired. IBM i expertise is concentrated among practitioners 55 and older, and many have already left the workforce. For many shops, all they have is a set of routines that run without anyone fully understanding why they were designed that way. I covered similar issues in a recent post about the backup illusion that puts IBM i environments at risk.
The fix starts with a structured assessment. It identifies where your environment stands, maps actual exposures, and determines which remediation steps should happen before any OS upgrade. Think of it as a health intake form: you cannot treat what you have not measured.
IBM i Security Standards and Regulatory Context
IBM i security posture does not exist in isolation. Organizations in healthcare, financial services, distribution, and manufacturing often carry obligations under frameworks including the NIST Cybersecurity Framework and CISA's operational technology security guidelines. Running an unsupported OS version with unpatched open-source HTTP vulnerabilities creates exposure not only to active attacks but to audit findings that require documented remediation. Compliance teams increasingly ask for evidence of patch currency. When the answer is "we are on a version IBM no longer supports," the conversation becomes significantly harder to manage.
A security assessment that documents your current state and a remediation roadmap gives you something to bring to that conversation before an auditor asks.
Common Questions About IBM i Security Risks
Are small IBM i shops actually targeted by cyber criminals?
Yes. Modern attacks rely on automated scanning tools that search for known vulnerabilities across the internet regardless of company size. A small shop running an outdated or unsupported OS version presents the same exploitable surface as a large one. Company size does not reduce exposure. It only reduces the likelihood that a human attacker hand-selects you.
What happens if my IBM i is running an unsupported operating system version?
IBM does not issue security patches for unsupported versions. Vulnerabilities discovered after IBM ended support for your version, including open-source HTTP vulnerabilities that recent patches address, remain unpatched in your environment. IBM cannot assist with those exposures regardless of your support agreement. For more on your upgrade path options, read our post about IBM i end-of-life decisions.
What is security level 20, and why does it matter before an OS upgrade?
Security level 20 is a legacy IBM i user profile setting that provides minimal system security. Users at that level can access far more than a well-designed security posture allows. When you upgrade to a current OS version, the system might not automatically correct those profiles. Inactive or replicated level 20 accounts require deliberate remediation before or immediately after an upgrade, because you cannot reverse the upgrade to address them later.
How do I know if my IBM i backups are actually working?
The only reliable method is a tested restore. Many IBM i shops have backup routines that complete without error but have never been validated through an actual restore exercise. A confirmed restore, not just a completed backup job, is the standard that auditors and disaster recovery plans should require.
What security risks do agile-developed or outsourced IBM i applications introduce?
Agile development teams optimize for functional delivery within a defined sprint. Security architecture across a full IBM i environment is rarely part of that scope. As a result, code may perform correctly while leaving open connections, unprotected APIs, or inadequate user authentication that automated scanning tools can identify and exploit.
What is zero trust, and are most small IBM i shops implementing it?
Zero trust is a security framework that verifies every user, device, and connection before granting access, regardless of network location. Most small IBM i environments are not fully implementing zero trust. Many still rely on perimeter-based assumptions, meaning that once someone is inside the network, they have broader access than a current security posture should allow.
What does a structured IBM i security assessment cover?
A thorough assessment covers OS version and patch currency, user profile security levels, and backup verification through a tested restore. It also includes open-source HTTP configuration status and any outsourced or agile-developed code that may not have been scoped for security. That baseline identifies whether you face immediate risk or longer-term planning needs before any major system change.
Find Out Where You Stand Before Something Forces You To
If your shop runs an unsupported OS version, the best time to address those security concerns is before an incident forces the question. Source Data team offers a security assessment that maps your actual exposures and outlines realistic next steps. Start the conversation with our team to request an assessment and begin on your timeline, not someone else's.
