Something you know.

Something you have.

Something you are.

Is it a riddle, or the opening words to a song?

Multi-Factor Authentication (MFA) improves security levels of the standard User Id and password combinations by introducing factors to increase the likelihood of a successful identification validation. The factors can contain the following:

Something you know: A username allocated to you by an administrator, an email ID, a password, or a PIN.

Something you have:  A token which generates One Time Passwords (OTP), an ID card, or a smartphone with a specific application.

Something you are: Fingerprint, Retina, facial or voice recognition.

Three levels of authentication can be obtained by using one item from each of these 3 factors – referred to as a 3 level authentication (3LA).

You might consider Location and Time as two more additional factors.

A smartphone might be used to scan your fingerprint and then register with a web application running on the mainframe. MFA related information can be added to the mainframe security system to declare MFA attributes related to the user. When the user requests a logon to a mainframe application the smartphone can display the OTP which can be copied to the password field in the application logon screen.

OTP have a limited time to be used before they expire and a replacement password is generated. Perhaps it is easier to wait for the new one to be issued to maximise the amount of time to enter the details into the logon screen.

For MFA to be successfully implemented the various factors used must be independent of each other i.e. access to one factor doesn’t automatically grant access to another factor. For example one password doesn’t grant access to the OTP and the email id.


MFA is not just focused on the user. Security administrators must also select which applications require MFA for users to logon to them.  The security requirements will change as the application passes through its development, implementation, and maintenance cycles.

MFA is flexible; there are options at the application level to check whether or not MFA is required. The MFA authentication can be bypassed for specific applications. Similar flexibility is available for users; a particular user can be bypassed within a group even though the rest of the group are required to provide MFA.

Operational considerations

The implementation of multi-factor authentication security solution requires appropriate careful planning. Advances in technology enrich software products in functionality but it is the operational deployment that can make a significant difference in how much success the business receives as a result.

The suggestions below are some of the aspects to consider for inclusion into your plan for implementing MFA.

A pilot migration to MFA will help you monitor the impact and identify any anomalies in the current practices that may require addressing.

The help desk (or service line) that deals with logon and security related calls will require education and extended procedures to deal with issues.  Examples could be:

The user uses a smartphone as part of the MFA but the smartphone has run out of power. The user has a second smartphone device but it is not registered.

The user is designated as requiring MFA credentials but the user id has expired.

The user’s password has expired.

The user does not know if he is expected to supply MFA credentials.

Allow a grace period for users to have password fallback while they adapt to the new procedures.

If smartphones are to be used, who will supply the users with the appropriate devices? Are users expected to use their own or will a device be supplied for their use? Do you have a BYOD policy?

Measure logon data to see how successful the pilot is. During the pilot phase (and throughout the implementation) analyse the logon data to understand the success rate and where problems lie.

Ensure security administration procedures are in place to deal with the migration schedule.

Include in your plan how Disaster Recovery (DR) will be handled.  Whether you have a hot site, cold site or somewhere between, you will have to consider how to manage DR testing and invocation.

The automation procedures will have to track address spaces required for MFA to function and alert immediately if there is a loss of availability.

Plan your MFA configuration across multiple systems within a sysplex.

Quality counts in MFA. If you are using fingerprints as part of the credentials the more accurate the image is, the more likely it is to be unique and therefore an effective identity validation. Partial images, or images taken by scanners with a poor resolution might reduce the accuracy of the image.

The use of additional factors for identity validation improves security levels and is likely to become common practice sooner than we think. Currently PCI DSS v3.2 requires an individual to present a minimum of two separate forms of authentication, before access is granted.

The success of adopting the MFA approach will depend on your reasons for the implementation, how the deployment is carried out, and your acceptance criteria. Internal and external influences will play a part in the outcome.

Editors Note: Keith Winnard is a mainframe consultant for Zeebizco Ltd. He recently returned to the UK after completing an engagement with the IBM Redbooks as z/OS project leader in Poughkeepsie, NY. He has 40 years of mainframe experience working within clients and vendors.  Also he is great guy to have a beer with…