2021 HelpSystems State of IBM i Security Study

State of IBM i Security Study

Organizations around the world are waking up to the business impact of lax cybersecurity: unexpected downtime, lost productivity, resources tied up in lawsuits and data breach notifications.
It’s no surprise 75 percent of IBM i pros rank cybersecurity as a top concern.
The latest State of IBM i Security Study—now in its 18th year—reveals concrete, impartial data about how IBM i systems are protected and where the gaps remain.

Executive Summary

Executive Summary

For the 18th year, this study provides compelling insight into the security posture of 247 IBM i servers and partitions—systems that are often used for business-critical data, payment card data, and personally identifiable information (PII).

This is not a recurring study of the same systems each year, but general trends are apparent. Cybersecurity is becoming a higher priority for participating organizations, and in recent years businesses have made gradual improvements with basic system security and password controls. However, many organizations are still in the early stages of implementing IBM i security controls.

Data from seven critical areas of IBM i security, summarized below, reveals the extent of the risk:

Security Enforcement Level

76% of systems follow best practices, but this setting can be undermined by other factors.

Users with Powerful Authorities

Overwhelmingly, the IBM i servers studied have too many profiles with powerful authorities. This could easily lead to data loss, theft, or damage. Auditors check for excess special authorities as part of any standard IBM i audit.

Password and Profile Security

25% of systems studied have more than 100 user profiles where the password matches the user name.

Access to Data

Virtually every system user has access to data far beyond their demonstrated need.

Network Access

Network access control and auditing is nonexistent in most IBM i shops, so both authorized and unauthorized access occurs without traceability. IBM i’s exit point technology provides the ability to control and monitor network data access, but adoption rates remain low.

Detecting Security Violations

Most lack an efficient strategy for monitoring and interpreting security event data, allowing violations to occur undetected.

Malware Protection

Virus and malware attacks have became even more brazen, but 90% of IBM i organizations still risk spreading malicious programs throughout their network.

About This Study

About This Study

Trends in IBM i Security

Cyberthreats grow more sophisticated every year, raising the importance of proper security controls. The 2021 State of IBM i Security Study proves that many organizations rely on system settings that leave data vulnerable.

But in recent years, HelpSystems has observed an encouraging trend: organizations large and small increasingly prioritize IBM i security.

A deeper understanding of the risks and the security controls built into the OS is currently driving a wave of interest in prioritizing cybersecurity issues on IBM i.

Why This Study Matters to You

The 18th annual State of IBM i Security Study strives to help you understand common IBM i security exposures and how to correct them quickly and effectively.

Your IBM i server likely runs mission-critical business applications. But because Windows and UNIX platforms often require more resources, it’s easy to let IBM i security projects take a back seat.

Consequently, the administration of IBM i security controls has lapsed even as threats to your system grow.

The weaknesses identified through our scans and documented in this study are caused by poor or missing configurations that can— and should—be corrected.

This study shows you the most common and dangerous IBM i security exposures and offers tips for improvement.


The data shared in this study is collected by HelpSystems security experts auditing IBM i systems using our Security Scan. This free software runs directly from any networkattached PC without modifying systems settings, interrogating Power Systems running IBM i (System i, iSeries, AS/400) across seven critical audit areas:

  • Server-level security controls
  • Profile and password settings
  • Administrative capabilities 
  • Network-initiated commands and data access
  • Public accessibility to corporate data
  • System event auditing
  • Virus scanning

This year’s study includes 247 IBM i servers and partitions that were audited in 2020. The average system scanned for this study has 1,056 users and 552 libraries. The majority of scanned servers were running on supported versions of the OS; however, 25% were on 7.2, which IBM is scheduled to stop supporting in April 2021.


Security Enforcement Level: QSECURITY

IBM i security best practices start with the configuration of numerous system values, which regulate how easy or difficult it is for someone to use or abuse your system. Poorly configured or unmonitored system values are an unacceptable security risk.


The system security level (QSECURITY) sets the overall tone, although it is often undermined by other settings. IBM recommends and ships security level 40 as the minimum, due to documented vulnerability found in level 30 and below. It should be noted that, despite the change to the default setting, a server migration will typically reload this to the same value as found on the previous generation of the server.

Figure 1 shows the distribution of security settings on the systems included in the 2021 dataset. Out of the 247 systems studied, 18 percent were running system security level 30 and eight percent were running at security level 20. Overall, 26 percent fell short of IBM’s recommended minimum level (Figure 1A). Many running on a sub-par security level are doing so without deliberate intent after having migrated their system values from an older server and are now recognizing the need to take corrective action.

System security level
Meeting the recommended minimum level



Bring your system up to QSECURITY level 40 or higher. Outsourcing this task to IBM i security professionals like the team at HelpSystems is a way to eliminate quickly all the guesswork from the process.


Basic System Security: Key Values for Restoring Objects

Several other system values related to object restoration often remain at their shipped levels, reflecting a typical IBM i configuration of "load and go.”

The system values in question are designed to work together as a filter that prevents restoration of malicious or tampered objects. But IBM i’s default values fail to provide this protection, which may leave the system vulnerable.

The system values below work consecutively to determine if an object should be restored, or if it is to be converted during the restore:

  • Verify Object on Restore (QVFYOBJRST)—More than 72 percent of servers are running below the recommended level of 3. This value, preset at level 1, controls whether a signature will be validated when a digitally signed object is restored.
  • Force Conversion on Restore (QFRCCVNRST)—94 percent of servers are running below the recommended level of 3. This value, preset at level 1, controls whether some types of objects are converted during a restore.
  • Allow Object Restore (QALWOBJRST)—Only four percent of servers had altered this system value from its default *ALL setting. This value controls whether programs with certain security attributes, such as system-state and authority adoption, can be restored.



A proactive approach to system values starts with defining and implementing a security policy that incorporates the most secure settings your environment will tolerate. (Seek professional expertise if you are unsure of the impact of certain settings.) The free open source IBM i Security Standard from HelpSystems can help you get started with defining your own policy.

Users with Powerful Authorities

Users with Powerful Authorities

IT professionals require special authorities to manage servers. These authorities can also permit the ability to view or change financial applications, customer credit card data, and confidential employee files. In careless, misguided, or malicious hands, a user with special authorities can cause serious damage.

IBM i special authorities are administrative privileges and always pose a security risk, so auditors require you to limit the users who have these special authorities and carefully monitor and audit their use. Of the special authorities, *ALLOBJ is the one providing users with the unrestricted ability to view, change, and delete every file and program on the system. This is sometimes referred to as “root” authority. As shown in Figure 2, this authority is granted to users in unacceptably high numbers.

Only three systems had 10 or fewer users with *ALLOBJ authority. The number of users who held *ALLOBJ was significantly higher than the previous year—an average of 30 percent of users this year compared to just 15 percent in the previous year. 

In addition to All Object, the most frequently granted special authorities were Job Control (*JOBCTL) and Spool Control (*SPLCTL), which were granted to 44 percent and 24 percent of users, respectively.

Job Control provides the capability to change the priority of jobs and printing, or even terminate subsystems in some cases. Spool Control enables users to fully access any spooled file in any output queue, regardless of imposed spool restrictions.

Special authorities



Keep the number of users with special authority to fewer than 10, or less than three percent of the user community. We recommend working with an IBM i security expert, who can advise on ways to determine if authorities are necessary and suggest possible alternatives in marginal cases. Here are some best practices for powerful users:

  • Document and enforce separation of duties for powerful users.
  • Avoid having any all-powerful users, all the time.
  • Monitor, log, and report on the use of powerful authorities.
  • Be prepared to justify the use of powerful authorities to auditors and managers.

Password and Profile Security: Inactive Profiles

Password and Profile Security: Inactive Profiles

Inactive profiles are user profiles that have not been used in the last 30 days or more. They create a security exposure because these accounts are not actively maintained by their users, which make them prime targets for hijacking.

Many of these inactive profiles belong to former employees or contractors—people who might carry a grudge or who might find their former employer’s data useful in their new roles at competitors.

The threat persists even if ex-employees never attempt to utilize these profiles. Other users within the organization might know, for example, that the former IT director’s profile is still on the system. And whether an inactive profile is exploited by a former employee, a malicious insider, or a hacker, unusual use of the profile won’t be detected and reported by the profile owner.

Figure 3 shows an average of 427 profiles (40 percent of the total) have not signed on in the past 30 days or more. Of these, 259 of them remain enabled and ready to be used.

Inactive profiles

Pro Tip 4


Develop a process for inactive profiles. Start by defining how long a profile must be inactive before you take action (perhaps 60 days), disable the inactive profiles, and remove all special authorities and group profile assignments. Wait another 30 days to make sure the profile really is inactive before removing it from the system, or until the name of the user is no longer required for reconciling with the audit trail.

This process can be performed manually or automated using IBM’s built-in security tools.

Password and Profile Security: Default Passwords

Password and Profile Security: Default Passwords

On IBM i, profiles that have a default password have a password that’s the same as the user name. Hackers—or even your own employees—can guess profile names like jsmith and try default passwords.

Regulatory and legislative standards typically mandate that users must utilize unique credentials known only to the user, ensuring that any actions can be tied to that specific individual. Organizations might struggle to prosecute illegal or unauthorized activity if it became evident that the credentials couldn’t unequivocally identify the culprit.

In this study, nearly 15 percent of user profiles have default passwords (Figure 4). 44 percent of the systems studied have more than 30 user profiles with default passwords. 25 percent are even worse off, with more than 100 users with default passwords. One system has a total of 5,604 user profiles with default passwords and over two thousand were in an enabled state.

default passwords

Pro Tip 5


Establish and enforce strong password policies. The QPWDRULES system value can ban default passwords, although consideration must be given to applications or vendor software that creates profiles during installation.

Reporting tools like Powertech Compliance Monitor for IBM i make it easy to generate audit reports on a regular basis that compare IBM i user and password information against policy.

Password and Profile Security: Password Length

Password and Profile Security: Password Length

Shorter passwords may be easier to remember, but they’re also easier for others to guess. Although short passwords can be strengthened by using random characters, the odds of correctly guessing a four-character password are greater than a longer password.

NIST now recommends using eight-character passwords, up from their previous recommendation of six characters.

Figure 5 shows the setting for the minimum password value on the systems reviewed. According to our results, nearly 30 percent meet or surpass the best practices standard of eight characters or more. 50 percent of servers in this study fail to satisfy PCI’s requirement of seven-character passwords. Shockingly, 15 percent of systems permit users to select a password that is less than six characters long and four servers permitted the use of single character passwords.

minimum password length

Pro Tip 6


Create a password policy that requires users to use eight or more characters in their passwords. Consider switching from passwords to passphrases, which are typically 20 to 30 characters long and make brute force attacks impractical.

Password and Profile Security: Other Password Settings

Password and Profile Security: Other Password Settings

IBM i allows systems administrators to define password policy at a granular level. Password settings include length, character restrictions, digit requirement, expiration time, and how soon a password can be reused.

These settings help make passwords harder to guess and increase the protection of your system, since simple, easy-to-guess passwords like “123456” and “password” that remain disturbingly common. Imagine what could happen if your users with simple passwords have special authorities or access to sensitive data.

The latest data shows that IBM i administrators aren’t utilizing all the password controls available to them:

  • 47 percent of systems don’t require a digit in passwords.
  • 93 percent of systems do not impose any restrictions on characters. Simply restricting vowels would add extra security by preventing users from choosing simple, easily guessable words for their passwords.
  • 26 percent of systems do not require passwords to differ from the previous password.

Password expiration is one area where we see progress. For the systems in our study, the average password expiration interval is 95 days.

Pro Tip 7


Require passwords of at least eight characters. IBM i can even support passwords up to 128 characters, which are more accurately called passphrases. Multi-factor authentication can also protect your systems from unauthorized access. Another option is eliminating passwords entirely by implementing single sign on (SSO) based on technology that is included in the IBM i operating system.

Password and Profile Security: Invalid Sign-On Attempts

Password and Profile Security: Invalid Sign-On Attempts

Passwords are forgotten, mistyped, or simply mixed up with other passwords. Help desk personnel charged with resetting these passwords often work with the same users over and over. How do you track which users have multiple invalid sign-on attempts? What if your powerful profiles are targeted? Larger numbers could indicate an intrusion attempt, while three, five, or even ten attempts are probably the sign of a frustrated user.

49 percent of systems had a profile that had experienced more than 100 denied attempts. 20 percent had more than 1,000 invalid signon attempts against a single profile. One system in our study had more than three million attempts against a single profile.

Figure 6 shows the action taken when the maximum number of allowed sign-on attempts is exceeded. In 95 percent of cases, the profile is disabled and this is always recommended. When using explicitly named devices (as opposed to virtual device names) the recommendation is expanded to include disablement of the device description. It is not recommended to disable virtual devices, as the system typically creates a new device when the user reconnects. The device setting does not apply to all connections, such as ODBC and REXEC services.

The other five percent of servers disable the device, but leave the profile enabled. This creates risk if the user re-establishes a connection, or perhaps connects to a service that does not require a workstation device.

Default action for invalid sign-on attempts

Pro Tip 8


To protect your system, make sure profiles are disabled by default after the maximum allowed sign-on attempts is exceeded. A tool for self-service password resets can help the users who have truly forgotten their passwords. Password Self Help for IBM i is one option that makes it easy for IBM i users reset a password and it sends instant alerts to designated personnel when unsuccessful resets occur.

*PUBLIC Access to Data

*PUBLIC Access to Data

On most servers, users typically have no authority to an object or task unless they’re expressly granted permission. With IBM i, every object has a default permission that applies to non-named users, known collectively as *PUBLIC. This default permission is initially set by IBM with enough authority to read, change, even delete data from a file. Unless the user is granted a specific authority (granted or denied access), the user can leverage the object’s default permission. When *PUBLIC access rights are left unrestricted, there is a risk for unauthorized program changes and database alterations—red flags for auditors.

This study uses the *PUBLIC access rights to libraries as a simple measurement indicating how accessible IBM i data is to the average end user. Figure 7 shows the level of access that *PUBLIC has to libraries on the systems in our study.

*USE: *PUBLIC can get a catalog of all objects in that library, and attempt to use or access any object in the library

*CHANGE: *PUBLIC can place new objects in the library and to change some of the library characteristics

*ALL: *PUBLIC can manage, rename, specify security for, or even delete a library (if they have delete authority to the objects in the library)

Our findings demonstrate that IBM i shops still have far too many libraries accessible to the average user—libraries that often include critical corporate information. With virtually every system user having access to data far beyond their demonstrated need, administrators need better processes to control access to IBM i data.

public authority to data

Pro Tip 9


Where possible, secure data using resource-level security to protect individual application and data objects. When this is not possible or practical, use exit program technology to regulate access to the data.

Ensure that application libraries are secured from general users on the system. (Although it requires some planning, consider setting the System Value and Library values for Default Create Authority to the most restrictive setting [*EXCLUDE].)

*PUBLIC Access to New Files and Programs

*PUBLIC Access to New Files and Programs

When new files and programs are created on most systems, the average user automatically has change rights to the vast majority of those new objects. Non-named users (*PUBLIC) have the authority to read, add, change, and delete data from the file. These users can copy data from, or upload data to, the file, and even change some of the object characteristics of the file.

This is because *PUBLIC’s authority to newly created files and programs typically comes from the library’s Default Create Authority (CRTAUT) parameter. Figure 8 shows that 16 percent of libraries had Default Create Authority set to *USE, *CHANGE, or *ALL. However, 82 percent of libraries deferred the setting to the QCRTAUT system value (*SYSVAL). Figure 8A extends the library level assignment of *SYSVAL and reflects that the system value typically remains at the shipped default of *CHANGE. Just three percent of servers are configured to default to the deny-bydefault requirement of common regulatory standards such as PCI DSS.

Another issue occurs when a user profile is created with permissions granted to the general user population (*PUBLIC). When *PUBLIC permissions exceed the strongly recommended setting of *EXCLUDE, this is known as an “unsecured profile.” It is possible for an alternate user to run a job that leverages the privileges of the unsecured profile. This activity will not be logged by the operating system as a security violation, since it is deemed permissible at all security levels. 197 systems have at least one unsecured profile and 59 systems have 10 or more profiles that are publicly accessible.

default create authority

Pro Tip 10


There’s a clear need to prioritize cybersecurity and implement security tools that provide users with secure, frictionless access to the data they need. Powertech tools can help with that.

Be sure to monitor changes to your database information, so you can meet compliance requirements.

Network Access

Network Access

Services such as FTP, ODBC, JDBC, and DDM can send IBM i data across the network as soon as the machine is powered on. All end users need is a free tool from the internet or even tools pre-loaded onto a PC. For example, Windows comes with FTP client software that easily sends or retrieves data from an IBM i server.

Some TCP services even permit the execution of server commands. The easily-accessed FTP service enables commands like Delete Library (DLTLIB) to be run by all users—even those without command line permission on their profile.

Firewall protection leads some IBM i pros to question whether systems are ever actually accessed in this way. However, the HelpSystems team recently witnessed an attack in progress where an intruder had successfully penetrated the perimeter and repeatedly tried to access a client’s system via FTP using several different user profiles, including ADMINISTRA and ROOT.

To reduce this exposure, IBM provides interfaces known as exit points that allow administrators to secure their systems. An exit program attached to an exit point can monitor and restrict network access to the system. An exit program should have two main functions: to audit access requests and to provide access control that augments IBM i object-level security. 

HelpSystems reviewed 27 different network exit point interfaces on each system to check whether an exit program was registered. 70 percent of the systems have no exit programs in place to allow them to log and control network access (Figure 9). Even on the systems with exit programs, coverage is often incomplete. Just 13% of systems have all 27 exit programs covered. Adoption of exit programs has grown steadily in recent years, but many companies are still unaware of this wide-open network access problem.

exit programs in place

Pro Tip 11


At organizations that lack a commercial-grade exit program solution, this tends to be the most highly prioritized remediation item. Without exit programs, IBM i does not provide any audit trail of user activity originating through common network access tools such as FTP and ODBC.

Organizations can write their own exit programs or use software to accomplish this. The advantage of commercial solutions like Powertech Exit Point Manager for IBM i is that you get broader coverage that protects all critical exit points.

Command Line Access

Command Line Access

The traditional way to control access to sensitive data and powerful commands was to limit command line access for end users. And in the past, this method was effective.

In addition to configuring the user profile with limited capabilities, application menus controlled how users accessed data and when they had access to a command line. However, as IBM opens new interfaces that provide access to data and the opportunity to run remote commands, this approach isn’t as sound as it used to be.

76 percent of users have had their command line access revoked and are unable to run most commands through traditional menu-based interfaces. 16 percent of users studied have both command line access and an enabled profile, which presents a very clear risk.

Several network interfaces do not acknowledge the command line limitations configured in a user profile and must be controlled in other ways. This means that users can run commands remotely, even when system administrators have purposely taken precautions to restrict them from using a command line.

Pro Tip 12


Based on the broad *PUBLIC authority demonstrated in earlier sections, anyone on these systems can access data, commands, and programs without the operating system keeping a record.

Start addressing this problem by reviewing network data access transactions for inappropriate or dangerous activity. Be sure to establish clear guidelines for file download and file sharing permissions. Remove default DB2 access in tools like Microsoft Excel, IBM i Client Access, and Access Client Solutions.

Security Event Auditing

Security Event Auditing

IBM i can log important security-related events into a tamper-proof repository—the Security Audit Journal. This feature allows organizations to determine the source of critical security events, such as “who deleted this file?” or “who gave this user *ALLOBJ authority?” This information can make the difference between responding promptly to a security event and discovering a breach after significant damage has occurred. The challenge is that the volume of data contained in the Security Audit Journal is large and the contents are cryptic. Most IT staff have trouble monitoring and making sense of the logged activity. 

16 percent of the systems reviewed do not have an audit journal repository. 19 percent of systems are operating with the QAUDCTL system value setting at its shipped value of *NONE (Figure 10). This is the master on/off switch for auditing and globally blocks any system or object level events from being logged, regardless of the existence of the system audit journal. Setting QAUDCTL to *NONE suggests that administrators fired up the auditing function but subsequently turned it back off or perhaps were unaware of the necessity for additional configuration.

When organizations have activated the Security Audit Journal, it’s unclear how much insight the extensive data is providing them. A few software vendors provide auditing tools that report on and review the system data written to the Security Audit Journal. But only 25 percent of the systems in this study have a recognizable tool installed.

audit journal

Pro Tip 13


Use the Security Audit Journal and automate the process of analyzing the raw data. Auditing tools reduce the costs associated with compliance reporting and increases the likelihood that this work will get done. IBM i security data can even be sent to your Security Information and Event Management (SIEM) solution in real time.

Virus and Malware Protection

Virus and Malware Protection

The traditional IBM i library and object infrastructure is considered highly virus-resistant, but other file structures within the Integrated File System (IFS) are susceptible to hosting infected files, which can then be propagated throughout the network. Recognizing this reality, IBM created system values and registry exit points to support native virus scanning a number of years ago. 

One business scanned IBM i for viruses for the first time and was shocked to find nearly 250,000 infected files. If anyone doubted the need for virus protection, this example proves the risk is real. Scanning IBM i for viruses and malware is becoming increasingly popular as administrators start to recognize that IBM i contains file systems that are not immune to infection and, under certain circumstances, native applications and even IBM i itself can be impacted. 

When the servers were reviewed for antivirus controls, 10 percent were scanning on file open, which is a noticeable increase over prior years. This means the other 90 percent are at risk of having internal objects impacted or of spreading an infection to another server in their network (Figure 11).

Scanning on IFS file open

Pro Tip 14


Register an exit program to exit point QIBM_QP0L_SCAN_OPEN to intercept file open attempts from the network and scan files before they are opened. This prevents viruses from spreading outside the IBM i environment.

Install an antivirus solution that runs natively on IBM i, such as Powertech Antivirus for IBM i, to detect and remove infections, as well as prevent malware from spreading beyond the current environment.  

In addition, utilizing an exit program registered to the QIBM_QPWFS_FILE_SERV exit point can help limit actions of remote viruses operating on other servers on the network.



IBM i has developed a reputation as one of the most securable platforms available. One of IBM i’s great advantages is that sophisticated tools for securing, monitoring, and logging are built into the OS. But experts agree that IBM i security is only as effective as the policies, procedures, and configurations put in place to manage it.

This study highlighted a number of common security exposures and configuration management practices that must be addressed to protect the data on IBM i systems. No system became vulnerable overnight, nor is it possible to fix every security problem in a single day. What’s important is starting somewhere and making continued progress toward a stronger security profile.

If you’re unsure how to proceed, start with top priorities for IBM i security:

  • System Security: Check the QSECURITY level and make sure it’s 40 or higher
  • Security Auditing: Enable QAUDJRN and find a tool to help interpret it
  • Network Access: Register the most common exit points like FTP and ODBC first
  • Reduce unnecessary user privileges

Most experts recommend starting with an assessment of vulnerabilities to understand where your system security stands today and how it could be improved. Security professionals with IBM i expertise and user-friendly software solutions are available to make this project faster and easier. HelpSystems offers a range of options, from a very thorough Risk Assessment to a quick, no-charge Security Scan.

Once you have all the information, you can begin formulating a plan that addresses your organization’s security vulnerabilities. And from there, security will become business as usual—not a moment of panic after a failed audit or a data breach.

HelpSystems Is Here to Help with IBM i Security

Check how secure your IBM i is with a Security Scan from HelpSystems. Security Scan is free, fast, and reveals your system’s security gaps. Our Security Advisers can then help you formulate a plan to remedy your security vulnerabilities.

Related Solutions

Stay up to date on what matters.