MFA: A Complete Guide to Affected Areas

This article continues our deep dive into Multi, Factor Authentication (MFA) on IBM i, focusing on the new features introduced in version 7.6.

If you’re new to MFA or need a refresher, you can start with the first part of this series, What is Multi, Factor Authentication? available here.

In this next article we will cover the _NC profiles, optional interval feature, per user customisation, monitoring and compliance, migration paths, network time protocol, coexistence with third party software, why this is 7.6 only and give our implementation recommendations.

Special Profiles: The _NC Profiles

To address automation challenges, IBM i 7.6 introduces new “non changeable” profiles:

QPGMR_NC

QSECOFR_NC

QSYSOPR_NC

QUSER_NC

These profiles, along with the new QIBM_RUN_UNDER_USER_NO_AUTH function usage ID, help prevent disruption to automated processes that traditionally run without interactive authentication.

Impact: Scheduled jobs using SBMJOB and APIs like Get Profile Handle may need modification to use these specialised profiles to maintain automated operations while enabling MFA for interactive users.

The Optional Interval Feature: Balancing Security & Usability

One of the most flexible aspects of IBM i 7.6 MFA is the TOTP optional interval setting which can be configured per user profile (1, 720 minutes).

How it works: After successfully authenticating with MFA, users won’t be required to provide their TOTP again for the specified interval. A valid user ID and password combination is still required for each authentication.

Example: If set to 60 minutes, a user who signs on to 5250 at 8:00 AM won’t need MFA again until after 9:00 AM, even when accessing Run SQL Scripts or other applications.

Impact: This feature allows administrators to:

Reduce authentication friction for applications not yet supporting TOTP fields

Ease the transition for users working across multiple interfaces

Maintain security while accommodating legacy applications

Maintain Third Party Applications and Vendor Software

Any third-party application or vendor software that authenticates users against IBM i, will be affected:

ERP systems using IBM i authentication

Custom developed applications

Middleware & integration tools

Backup & monitoring software

Impact: Vendors will need months or potentially years to update all interfaces. In the interim IBM’s password:TOTP concatenation workaround and the optional interval feature provide compatibility solutions.

Configuration Flexibility: Per User Customisation

IBM i 7.6 MFA provides unprecedented flexibility on a per user basis.

Each user profile can be configured with:

Whether MFA is required (AUTHMTH(*TOTP))

The optional interval duration

Different authentication requirements based on job function

Impact: Security administrators can implement a phased rollout, starting with powerful profiles (*ALLOBJ special authority) and gradually expanding coverage based on risk assessment and operational readiness.

Monitoring & Compliance

New fields have been added to the QSYS2.user_info SQL view to track MFA configuration status:

Which profiles are enrolled in MFA

Which profiles are required to use MFA

MFA configuration details per user

Impact: Administrators can query these views to generate compliance reports and monitor MFA adoption across the user base.

Migration Path: Green Screen Enrolment Alternative

While Navigator for i provides the recommended enrolment interface with QR code scanning, IBM also supplies the CHGTOTPKEY command for green screen enrolment. However, this interface is significantly less user friendly and should only be used when Navigator access is not available.

Network Time Protocol (NTP) Requirement

For IBM i MFA to function correctly, the system time must be synchronised with the authenticator app’s device time. Both use UTC timestamps to generate TOTP codes.

Impact: Organisations should configure Network Time Protocol (NTP) servers to ensure accurate time synchronisation between IBM i and user devices.

Coexistence with Third Party MFA Solutions

IBM’s native MFA doesn’t replace existing third-party MFA solutions, it can work alongside them or independently:

Complementary mode: Use IBM MFA for some interfaces and third party solutions for others

Hybrid approach: Leverage IBM’s comprehensive authentication coverage with third party features like push notifications

Standalone mode: Use only third party MFA by not enabling the Additional sign on factor security attribute

Impact: Organisations with existing MFA investments can integrate IBM’s solution incrementally or maintain their current approach while gaining IBM’s system wide authentication coverage.

Why This is 7.6 Only (No PTF for Older Releases)

The MFA implementation required changes throughout the entire IBM i operating system, from the lowest level authentication APIs to every sign on interface. This extensive integration work, which took over four years to complete, is why:

MFA is only available on IBM i 7.6

It cannot be added to older releases via PTF

It represents a “massive security improvement” built into the OS foundation

Implementation Recommendations

Based on the comprehensive scope of MFA’s impact, consider this phased approach:

Phase 1: Enable MFA for all *ALLOBJ profiles (highest risk)

Phase 2: Identify and configure automated processes with _NC profiles or optional intervals

Phase 3: Roll out to interactive users by department or function

Phase 4: Roll out to interactive users by department or function

Phase 5: Gradually reduce or eliminate optional intervals as applications are updated

Conclusion

IBM i 7.6’s native MFA touches virtually every authentication point in the operating system, from traditional 5250 signons to SSH connections, from Navigator for i to system service tools.

This comprehensive coverage, only possible because IBM has access to all authentication interfaces, represents a fundamental shift in IBM i security.

While the scope of impact is broad, IBM has provided extensive flexibility through optional intervals, specialised profiles for automation, and per user configuration options.

This allows organisations to implement MFA at their own pace while maintaining operational continuity.

The key to successful implementation is understanding which interfaces your users and automated processes rely on, planning appropriate configurations for each scenario, and educating users about the changes they’ll experience.

With proper planning, IBM i 7.6 MFA can deliver the “massive security improvement” IBM promises without disrupting business operations.

For detailed implementation instructions, consult the IBM i 7.6 Multi-Factor Authentication (MFA) manual available at the IBM Documentation site.

Welcoming the IBM Community

MFA: A Complete Guide to Affected Areas – Part 2