Answer
A practical sequence starts with the smallest, highest-risk group first, typically QSECURITY administrators and anyone with *ALLOBJ or *SECADM special authority, since a compromised admin credential is the fastest path to a full system breach. Pilot MFA there, work out the recovery process for lost tokens or failed logins, then expand to remote access users connecting over VPN before touching the broader interactive user base. Service accounts and batch jobs need a separate conversation entirely, since most MFA products cannot prompt a job scheduler or an unattended FTP connection for a one-time code, so those accounts typically need compensating controls like IP restriction, exit point monitoring, and tighter object authority instead of MFA itself.
Buyers should press vendors on exactly how the product hooks the 5250 sign-on screen, since some tools intercept the standard sign-on API cleanly while others require a modified sign-on program or a proxy that adds a second network hop. Ask what happens when the MFA service is unreachable: a poorly designed integration can lock every user out of a green-screen session during an outage, which is worse than no MFA at all. It is also worth asking how the vendor handles emergency break-glass access for QSECOFR, since that account needs a documented exception path that is still logged and reviewed, not a permanent bypass that quietly undoes the whole project.