With both security and the user’s experience in mind and in accordance with the NIST definition of Multi-Factor Authentication, the AffirmedID authentication ceremony consists of three steps with only one redirect:

1. On login to an application, a push notification is sent to their cell phone AffirmedID authenticator app;
2. It verifies user PIN and their behaviors (device gestures, actions, and patterns) and;
3. A tap gesture initiates verification of an FIDO2 assertion and identity proofs, followed by a redirect to;
4. The application.

A secure and seamless transition from login to application use with verification of both user and device identity done on behalf of the relying party. Not said but certainly available are the options of:

• Relying party verification of both user and device identity assertions;
• Commencement of SIEM event logging; and
• Seamless transition to Continuous Authentication monitoring.

On the surface, the adoption rate of MFA use is encouraging, with surveys indicating 87% of enterprises and 26% of SMBs are now using some form of MFA. Impressive until we drill down to learn that 80% of reporting enterprises and 70% of SMBs consider 2FA in the form of One-Time Passwords (OTP) to meet their definition of MFA.

Understanding the ever-increasing reports of 2FA bypass attacks in view of these statistics becomes much easier. Indeed, this form of MFA approximates securing the physical plant using a hasp.

The cyber experts at NIST define MFA as “two distinct factors that are independently verifiable by the system.” An OTP code combined with a password are two forms of a single factor, “something you know.”

Also, FIDO2, Passkey, and Passwordless Push are different forms of the single factor of “something you have.”

AffirmedID is one of the very few authenticators that meet the NIST definition of MFA, and hence why we call it “Real MFA”.

That’s not to say other solutions do not provide MFA, but they do so at the expense of the user.

A leading supplier of network hardware, software, and services offers an MFA solution that:

1. On login to an application, it initiate a Passwordless Push Authentication request to its app running on your cell phone.
2. On accepting the push offer, redirect to;
3. Windows Hello which redirects to;
4. Passkey which redirects to;
5. The application.

Another major supplier of OS, applications, and cloud services provides an MFA solution that:

1. On login to one of its applications, it redirects to;
2. The licensing MSP login that redirects you to;
3. An OPT code displays on the authenticating device that redirects to;
4. The supplier’s cell phone authenticator that takes OTP code input and redirects to;
5. The cell phone Passkey that redirects to;
6. The application.

The two authentication ceremonies of the first example and the three ceremonies of the second absolutely meet NIST requirements but do so at the expense of the user.

Other equally compliant methods are somewhat more user-friendly but require continued use of the password combined with FIDO2 or Passkey as a second factor.

Caveat: As of the date of this writing, the FIDO2 and Passkey User Verification (UV) options are not considered a factor by NIST. However, now in review, there are adjustments to NIST standards to allow accepting in less sensitive settings either a FIDO2 or Passkey ceremony as MFA should UV be requested by the relying party and provided by the authenticator. Given the impossibility of verifying the methods used to form UV opinions, it seems this exception does not apply where Zero Trust Architecture (ZTA) is the aim.