3 Zero Trust Myths That Are Leaving Your IBM i Unprotected

Zero Trust has become the security model most companies build around. NIST, which maintains the framework most vendors and auditors point back to, defines it as an approach that narrows defenses from wide network perimeters down to individual resources, rather than assuming anything inside the network is automatically safe. Most organizations have rolled that thinking out across their Windows, Linux, and cloud environments.

IBM i is usually the one system left out, not because anyone decided it didn’t need protecting, but because a few common assumptions keep it off the list. Here are the three we run into most often, along with what current industry data says about how widespread the gap actually is. They’re part of a longer list of common gaps, which we’ve broken down separately in Top 7 IBM i Security Vulnerabilities.

Myth #1: “We already have enterprise security software, so IBM i is covered.”

Most companies have a corporate firewall, MFA at the network level, and monitoring software running across their Windows and Linux servers. It’s a fair assumption that this coverage extends to IBM i too.

Usually it doesn’t. The enterprise security platforms protecting the rest of the network typically have no coverage built for IBM i, including the Integrated File System (IFS), which often ends up running with no monitoring at all. That’s not a small or rare gap. The latest annual IBM i security study, now in its 23rd consecutive year analyzing production IBM i partitions, found that while 73 percent of systems now have at least one exit program in place (up from 58 percent the year before), only 31 percent cover all 27 of the access points the study tracks (IT Jungle).

In plain terms, most shops have started the work but very few have actually finished it. Which leaves an unmonitored IFS as a workable landing spot for ransomware, viruses, or malware, with nothing watching for it.

Worried about ransomware specifically? Read IBM i Ransomware Protection: 5 Steps to Secure Your Systems for a closer look at what that protection actually involves.

Myth #2: “Our IBM i is in the cloud, so it’s already secure.”

More small and mid sized companies are moving IBM i off on premises hardware and into the cloud, and this assumption is moving with them. Cloud managed services providers do deliver real security value: VPN connectivity, SOC 2 compliant infrastructure, protection that’s genuinely useful at the infrastructure level.

The part that’s easy to miss is that infrastructure security and IBM i security are two different things. A cloud provider secures the environment IBM i runs in. It doesn’t monitor or secure IBM i itself. Moving to the cloud changes where the server lives. It doesn’t remove the need for a Zero Trust approach on the server itself, and the access-control gaps described below don’t go away just because the hardware is hosted somewhere else.

For a closer look at where that responsibility split actually falls, see How to Secure Your IBM i Workloads in the Cloud.

Myth #3: “We don’t store sensitive data on IBM i, so there’s nothing to protect.”

For a lot of companies, that’s technically true. IBM i usually isn’t where social security numbers or credit card numbers live. But it’s often where the business actually runs: the mission-critical operations and the proprietary logic built into daily workflows.

A better question than “what’s stored here” is:

• What happens if this system is down, corrupted, or unavailable for a day?
• What does that cost in downtime?
• What does recovery cost?

For most IBM i organizations, that answer makes the case for Zero Trust on its own, regardless of what type of data is technically sitting on the server. It also matters more than most teams assume: the same benchmark study found that 30 percent of libraries still allow *PUBLIC read access and 43 percent allow *PUBLIC data modification. That means close to half of the systems studied would let any authenticated user change data they may have no business touching, sensitive or not.

Key Terms to Know

Since some of this gets technical fast, three terms worth defining before we go further:

• Exit point security is a layer that sits inside the network and checks what each connection (ODBC, FTP, SQL, a web app, and so on) is actually allowed to do on the IBM i, rather than just whether the connection is allowed to exist.
• Least privilege means giving each user account only the access it needs for its actual job, so a compromised account can’t reach everything on the system just because it reached something.
• *PUBLIC authority is IBM i’s default access setting. When it’s left open, it effectively means “everyone on the system,” which is exactly the setting the statistics above are describing.

Inside a Real Phishing Attack

Here’s a common scenario: an employee with full network access opens a phishing email and clicks a bad link. Malware lands on their workstation and starts looking for other systems on the network to spread to.

The Windows and Linux servers usually hold up. They’re running endpoint protection built specifically for those platforms. IBM i typically isn’t covered by that same protection, even though the employee authenticated through MFA and connected over VPN the whole time. The malware finds the one system with nothing watching it, settles into the IFS, and in some cases uses that foothold to spread back out into the rest of the network.

This isn’t a knock on MFA or VPNs. Both are doing their job. The problem is that once malware is using a real employee’s login, the system has no way to tell the difference between that employee and the attacker. That’s the idea behind Zero Trust: build in protections that hold up even when the credentials look completely legitimate. It’s also why account hygiene matters as much as perimeter defense.

The same benchmark IBM i security study found 10 percent of user profiles across the systems studied still had default passwords, and 31 percent of partitions had 1,000 or more profiles carrying defaults. Those are exactly the accounts a phishing-driven attack looks for first.

The Layers That Close the Gap

None of this means starting over. It means adding the protection IBM i is usually missing, starting with network level exit point security and object and IFS level permissions built on least privilege, so one compromised account can’t reach everything on the system. From there, companies often add privilege escalation controls, IBM i specific MFA, and tighter default user permissions.

Every layer added makes a successful breach harder to pull off, and the data backs that up directionally too: exit point coverage has more than doubled industry wide in two years (35 percent in 2024 to 73 percent in 2026), which tracks with a broader shift toward treating IBM i as its own attack surface rather than an assumed-safe system inside someone else’s perimeter.

Want to see exactly how this plays out, including how a Zero Trust setup stops the phishing scenario above before it reaches the IFS? Watch the full session below. And if you’d rather hear it as a conversation, our Fresche Talks episode on IBM i cloud security covers a lot of the same ground in a fact-or-fiction format.