Description: Customer accounts must have the option to be protected through strong authentication (MFA) to minimize the likelihood of a breach. This protection has to happen:
- On first login to a new user account
- On a subsequent login a step-up may be required to achieve a higher level of trust where the trigger is based on high risk events
- During a previously authenticated session as voluntary enrollment
- During a previously authenticated session, when a step-up is required to achieve a higher level of trust based on a policy where the trigger is something that the customer is trying to do (e.g. to perform a funds transfer)
- During a previously authenticated session, when a step-up is required to change any aspects of the multi-factor authentication configuration or contact information on which MFA may be dependent
In all these cases, the identity of the user has to be determined using a strong level of assurance.
Benefit: Protect customer identities and reduce the risk of account takeover or credential theft, as well as, ensure organization fulfils regulatory requirements and audit compliance.
Implementation Approaches
Security Frameworks
NIST Cybersecurity Framework 1.1
- PR.AC-7: Users, devices, and other assets are authenticated (e.g., single-factor, multi-factor) commensurate with the risk of the transaction
NIST SP 800-207; Zero Trust Architecture
- 2: Overall, enterprises need to develop and maintain dynamic risk-based policies for resource access and set up a system to ensure that these policies are enforced correctly and consistently for individual resource access requests
- 2.1.6: This includes the use of multifactor authentication (MFA) for access to some or all enterprise resources.
NIST SP 800-63; Digital Identity Guidelines
- NIST 800-63B, 4.3: Authenticator Assurance Level 3 (AAL3). Privileged access is to the most sensitive data which requires MFA based on proof of possession of a key through a cyrptographic protocol.
- NIST 800-63B, 4.5: Table 4-1 shows permitted authenticator types for MFA to achieve AAL3.
- NIST 800-63B, 5.1: Documents permitted authenticator types for MFA.
- NIST 800-63B, 6.1.2: Post Enrollment Binding describes the strong authentication requirements of binding, adding, or replacing an authentication factor.
| Title | Self-contained agent based MFA |
| Technology Components | Multi-Factor Authentication (MFA) |
| Description | The MFA capability is tightly integrated with any application. For example, SaaS application vendors can also offer MFA either as an integral part of its own offering. In this case MFA is available out of the box. There is no dependence on an external service or Access Management (AM) solution. |
| Pre-requisites | Native bundling of MFA capability into an application Appropriate policies are defined to force MFA when necessary |
| Supporting Member Companies | There is no dependence on an external service or Access Management (AM) solution |
| Title | Delegated MFA Using an External Service |
| Technology Components | Access Management (AM) |
| Description | In this approach, the MFA capability is loosely integrated between a brands application (web portal, or application), and an external service For example, an application vendor can offer simple authentication (perhaps a username/password knowledge based proof of identity) but does not offer MFA. The stronger MFA proof of identity is done through integration with an external (3rd party) service. This integration can done over any of the following protocols:REST APIFederation protocols such as OIDC or SAML, where token generation is gated by the MFA capabilityIn all cases, customer access is granted only after a successful MFA response from the external service. |
| Pre-requisites | Initial registration/enrollment is required to use MFA capability of external service MFA capability is available through the external service The application integrates with an external service for MFA whenever it needs to provide a challenge |
| Supporting Member Companies | ForgeRock, Okta, Ping Identity, Strivacity |
