Why user profile security is a critical defense against modern phishing and AI-driven attacks.

By Pauline Brazil Ayala

The latest cyberattacks don’t always begin with an operating system vulnerability. A common and effective attack path is the takeover of a legitimate user’s account. Phishing attacks, increasingly enhanced by AI, are designed to steal credentials and bypass technical defenses entirely. When a user is compromised, an attacker can exploit all the access that user has across the corporate environment.

Without strong controls such as multi-factor authentication (MFA), complex password policies, and a least-privilege access model, a single compromised profile can provide far more access than intended. In those scenarios, attackers don’t need to defeat IBM i security—they simply use it.

In the IBM i security assessments I perform, the same issues surface repeatedly: excessive *PUBLIC authority, privileged user profiles, inactive or orphaned accounts, weak passwords, and default passwords. These are not advanced attack techniques or obscure configuration errors. They are basic user profile hygiene issues—and they represent critical risk because user profiles are often the first point of compromise. At the same time, they are among the easiest security weaknesses to correct.

AI is further dismantling the long-standing assumption that IBM i benefits from “security through obscurity.” Today, attackers can quickly learn IBM i commands, authority models, and common misconfigurations using publicly available information and AI tools. While AI is driving efficiency and innovation, it is also amplifying the effectiveness of phishing and credential-based attacks. As a result, securing basic access controls on IBM i is more important than ever.

The good news is that meaningful risk reduction does not require replacing applications or redesigning architectures. The fastest and most impactful improvements begin with tightening user profile security. So where should IBM i teams focus first? Let’s take a look at a few key areas.

Minimize Privileged Users

Privileged user profiles pose the highest risk on an IBM i system. If a profile with elevated authority is hijacked, an attacker can immediately access sensitive data, modify system objects, or disable security controls. In many environments, the number of privileged users is very high, often without clear business justification.

When evaluating whether a user has excessive privilege, pay close attention to the following attributes:

• Special authorities, particularly *ALLOBJ (access to all objects on the system) and *SECADM (security administration privileges)
• Limit capabilities, which should be enabled for users who do not require unrestricted command line access
• Authority inheritance from Group profiles and Supplemental group profiles

Each of these attributes can expand what a user can do on the system. The goal is not to eliminate privileged access entirely, but to ensure that it is tightly controlled, well understood, and limited to users who genuinely require it.

A practical rule of thumb is simple: if a user does not need a privilege to perform their daily job, they should not have it. Reducing the number of privileged profiles dramatically limits the potential impact of an account takeover.

Sample SQL to Review User Profiles

SQL scripts can be used to retrieve user profile information for review. The following example uses the QSYS2.USER_INFO view and provides visibility into which profiles have special authorities, whether profiles are enabled, and recent sign-on activity—key data points when reviewing privileged access.

SELECT AUTHORIZATION_NAME,

       STATUS,

       PREVIOUS_SIGNON,

       PASSWORD_CHANGE_DATE,

       SPECIAL_AUTHORITIES

FROM QSYS2.USER_INFO

ORDER BY AUTHORIZATION_NAME;

Here is another example that would focus specifically on profiles with elevated authority:

SELECT AUTHORIZATION_NAME,

       STATUS,

       SPECIAL_AUTHORITIES

FROM QSYS2.USER_INFO

WHERE SPECIAL_AUTHORITIES <> '*NONE'

ORDER BY AUTHORIZATION_NAME;

DSPUSRPRF Command

To review user profile information from a command line, use the Display User Profile command:

DSPUSRPRF USRPRF(USERID) TYPE(*BASIC) OUTPUT(*)

This command displays special authorities, user class, limit capabilities, group profile relationships, and profile status, along with many other user profile attributes—making it useful for spot checks and validation. Output can also be directed to an output file for further querying.

By routinely reviewing and reducing privileged user profiles, organizations can significantly lower risk. Even if credentials are compromised, limiting privileged access helps ensure the resulting impact is contained.

Strengthen Password Policy

Weak passwords remain a common target for brute-force attacks, but many systems are still configured with outdated password settings. To create and enforce a complex password policy, leverage the OS's password-related security system values and standardize password expiration.

Start by ensuring the system password level (QPWDLVL) is set to the highest possible value. 128-character passwords have been supported for many years, and IBM i 7.5 further enhanced password protection with password level 4. Unfortunately, many environments still have password levels 0 or 1 configured, which rely on 10-character, all-uppercase passwords—credentials that can be cracked in a negligible amount of time with modern tools. Moving up to password level 2, 3, or 4 gives you the flexibility to increase the password length to 128 characters, enable mixed case, and use a stronger encryption algorithm, with password level 4 providing the strongest encryption available on IBM i.

Changing the password level requires careful planning to avoid application disruptions and the risk of users being unable to sign in to the system. Also, reverting back to a lower password level is not always straightforward. However, the security benefits far outweigh the effort involved.

Another important consideration is password expiration. It is recommended that user profiles be configured to use the system value (*SYSVAL) for the password expiration interval to ensure a uniform expiration standard. This means the password expiration interval for all users would be controlled by the QPWDEXPITV system value, which can be set to align with your security policy—typically around 90 days. This ensures that even if credentials are compromised, their usefulness is time-limited. It also ensures you do not have users with passwords that are never changed, a configuration you want to pay particular attention to for privileged users like administrators.

The password composition rules should also be sufficiently complex. QPWDRULES provides multiple values to customize password requirements and is generally used as the standard for configuring password complexity, replacing many of the older individual password-related system values. Choose a set of values that strikes a balance between sufficient complexity and avoiding frustration when users create a new password.

The QPWDRULES password rules system offers numerous options. Some important ones to consider:

*LMTPRFNAME - ensures the user profile name is not used in the password

*ALLCRTCHG - prevents admins from bypassing password rules in the CRT and CHGUSRPRF commands

*MIXCASEn - requires ’n’ number of upper and lowercase letters in the password

*MAXLENnnn - sets ‘nnn’ as the maximum password length

*MINLENnnn - sets ‘nnn’ as the minimum password length

*REQANY3 - requires passwords to contain all types of characters, depending on the password level

*SPCCHRMAXn - sets ’n’ as the maximum number of special characters in the password

*SPCCHRMINn - sets ’n’ as the minimum number of special characters in the password

Another critical point to remember when managing passwords: do NOT share them! Assign unique user profiles to each person accessing the system, and require a password change at first sign-on.

Add Multi-Factor Authentication

Multi-factor authentication (MFA) can reduce the risk of account takeover by adding an additional layer of verification beyond the password. A common implementation is to require entering a token generated by a third-party authenticator app after entering a username and password on the sign-on screen.

Many organizations already use third-party MFA solutions for IBM i. Another option recently introduced in IBM i 7.6 is a native MFA integrated into the base operating system. Along with the configuration required to use IBM’s MFA (see: https://www.ibm.com/docs/en/ssw_ibm_i_76/pdf/mfapdf.pdf), there are a couple of important prerequisites. The QPWDLVL system value must be set to level 4, and the minimum QSECURITY system value level is 40. If your system is not at either of these values, be sure to plan carefully to transition to these system values smoothly. This will help ensure applications continue to function properly and that users can sign in successfully when you make the changes.

Decommission Inactive User Profiles

Inactive user profiles unnecessarily expand a system's attack surface. A common best practice is to disable user profiles after 30 days of inactivity and delete user profiles after 90 days of inactivity, subject to business and regulatory requirements.

When reviewing inactivity, it is important to pay attention to the user profile's Last Used Date and Previous Sign-on Date. Profiles restored from backup may show a recent last-used date that does not reflect actual usage, making the previous sign-on date a more reliable indicator.

Service accounts require special consideration. Many users do not sign in interactively and may not have passwords, so the Last Used Date is better for evaluating inactivity. These profiles should be reviewed carefully to confirm that their purpose is documented, their authorities are minimal, and their usage is legitimate.

If a profile must be retained beyond standard inactivity thresholds, the business justification should be clearly documented. Auditors will almost always question inactive profiles without a strong explanation.

Continuously Monitor User Profiles

Remediation is not the end of the process. User profile security must be reviewed continuously to remain effective.

New users are added, roles change, and temporary exceptions become permanent if they are not revisited. Regular reviews of user profiles, authorities, password settings, and system values are essential to maintaining compliance with security policy.

In practice, user profile hygiene should be treated as an ongoing operational task—not a one-time cleanup effort. Consistent monitoring ensures that even if an account is compromised, the resulting damage is limited by design.

Conclusion

Even with all the security strengths of IBM i, ultimately, security is only as strong as the user profiles that operate within it. As phishing attacks become more sophisticated and effective through AI, attackers are increasingly bypassing technical controls and relying on compromised credentials to gain access. In that model, excessive privileges, weak passwords, and inactive user profiles are no longer minor oversights—they are direct enablers of compromise.

By focusing on user profile hygiene—minimizing privileged access, enforcing strong authentication, removing inactive accounts, and continuously monitoring changes—IBM i teams can significantly limit the impact of account takeovers when they occur.

In a world where attackers log in rather than break in, securing user profiles on IBM i is no longer just a best practice. It is a foundational security requirement.