Answer
Most products implement this through one of a few mechanisms: a modified sign-on exit program that intercepts the standard 5250 sign-on API, a RADIUS integration sitting in front of VPN or terminal emulation, or an agent that challenges specific commands like a change to a user profile or a QSECOFR-level authority grant. Each approach has different failure modes. Exit-program-based MFA tends to be the most transparent to end users but requires more careful testing against custom sign-on programs some shops have layered on over the years, while RADIUS-based approaches are easier to deploy broadly but may only cover the network perimeter, leaving internal green-screen sessions unprotected.
The practical test during evaluation is to walk through a real user's day: they sign on at a workstation, connect to a second session over 5250 emulation from home, occasionally use FTP to move a file, and once a quarter need emergency access when the on-call admin is unreachable. Ask the vendor to show, session by session, where the MFA prompt appears and where it does not. Also ask how token enrollment and recovery work for a workforce that may include older RPG and COBOL developers who are not used to authenticator apps, since a rollout that assumes universal smartphone comfort will generate support tickets for months.