In the era of PCI DSS 4.0 and Zero Trust Architecture (ZTA), achieving multi-factor authentication (MFA) for security or regulatory compliance poses a dual challenge. On the one hand, there is the need to achieve strong MFA, while on the other is the ZTA imperative of 'never trust, always verify’.

Considering this, we find that some MFA solutions fail to deliver multiple factors, for example:

• FIDO2 and Passkey confirm use of a device, a single factor. Either can contribute to a strong MFA but neither on its own equals MFA.. And no, the gesture each require although proving human presence, is not considered a factor by NIST or PCI DSS.
• Another pseudo-MFA is the OTP code. Inability to verify its origin reduces its contribution to a single something you know factor.
• Passwordless push is likewise a single factor, proof of device possession which is, something you have.

Either of these, when combined with another distinct factor provides pretty good MFA, so long as ZTA’s ‘always verify’ rule is met.

The impetus for AffirmedID was the recognition that authenticators at the time did anything but verify a person's digital identity. From the SecureID introduced in 2002 to the YubiKey of today are tokens that ostensibly prove one is who they claim to be without actually doing so.

Ultimately, multi-factor authentication must achieve two objectives: verifiable recognition of the person and indisputable proof of the device identity used to do so. Tightly coupled objectives where one cannot exist without the other. In other words, neither FIDO2 nor Passkey require user verification. So, accepting that their assertion was preceded by device login is an assumption.

By design, the FIDO2 authenticator of AffirmedID is not available for use until user identity is verified by PIN, something you know, and biometrics, something you are. Only then can the FIDO2 authenticator assert its device identity, something you have. A cause-and-effect design and implementation.

Continuity of trust is a compelling yet seldom considered concept. Simply put, the trustworthy fact produced by a remote authentication process must be equally trustworthy when received by the service provider. In other words, mitigating the risk of man-in-the-middle intervention is incredibly difficult where BYOD devices and browsers are used for authentication.

The difficulty and cost of extending phishing resistance of FIDO2 (or Passkey) to BYOD devices may be impossible or out of reach for many organizations and the risk of shadow IT may netrualize the benefits for those who can.

AffirmedID's elegant yet simple solution to this otherwise intractable problem transfers FIDO Client responsibilities to the cloud. This method ensures a secure connection between the authenticator app and the FIDO Client in the cloud, achieved through strong end-to-end encryption using TLS protocols and secure communication via out-of-band networks.

The astute reader might point out the potential loss of benefits of a bonding between FIDO2 (or Passkey) authenticator and its FIDO Client running in a browser on a local device. AffirmedID addresses this in two ways. Its proximity biometric bonds the local device to the authentication process with no intervention or awareness on the part of the user. Alternatively, its configurable FIDO2 over Bluetooth to a localized FIDO Client device can be used in parallel with the cloud implementation. This latter approach impacts the user experience.