Description: All user accounts (employees, contractos, third party partners) must provide the option to be protected through multi-factor authentication (MFA) to minimize the likelihood of a breach. This protection has to happen:
- On first login to a new user account
- During a previously authenticated session, as voluntary enrollment during a grace period or enrolment window
- During a previously authenticated session, when a step-up is required to achieve a higher level of trust (e.g. to access a restricted part of an application based on a policy where the trigger is something that the user is trying to do)
- 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, 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 user has to be determined using a strong level of assurance.
Benefit: Protect company identity and assets from breach, help fulfil regulatory and audit compliance.
Implementation Approaches
- Self-contained Agent-based MFA
- Delegated MFA Using an External Identity Provider
- Delegated MFA and AM Using an External Identity Provider
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, without any external integration. There is no dependence on an external Identity Provider (IdP). |
| Pre-requisites | Native bundling of MFA capability into an application Appropriate policies are defined to force MFA when necessary |
| Supporting Member Companies | N/A |
| Title | Delegated MFA Using an External Identity Provider |
| Technology Components | Access Management (AM) |
| Description | In this approach, the MFA capability is loosely integrated between the service provider, and an external Identity Provider. 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) Identity Provider. This integration can done over any of the following protocols:Federated model using SAMLFederated model using OIDCNon-federated model using RADIUSIn all cases, privileged access is granted only after a successful MFA response from the Identity Provider. |
| Pre-requisites | MFA capability is available through IAM The service provider integrates with IAM for MFA whenever it needs to provide a challenge Appropriate policies are defined to force MFA when necessary |
| Supporting Member Companies | ForgeRock, Okta, Ping Identity |
| Title | Delegated MFA and AM using an external Identity Provider |
| Technology Components | Multi-Factor Authentication (MFA) |
| Description | This approach is somewhat similar to Approach #2. The difference is that in this approach, in addition to MFA capability, the AM capability is also loosely integrated between the service provider, and an external Identity Provider. For example, an application vendor can offer simple authentication (perhaps a username/password knowledge based proof of identity) but does not offer MFA or AM. A context based stronger MFA proof of identity (when needed) is done through integration with an external (3rd party) Identity Provider. This integration can done over any of the following protocols:Federated model using SAMLFederated model using OIDCNon-federated model using RADIUSIn all cases, application access is granted only after a successful MFA response from the Identity Provider. The IdP may bypass actual MFA with the user, if the policy allows it. For example, if an MFA was successfully completed with a user a short while ago, a subsequent request for MFA may be silently accepted and returned to the service provider without involving the user. This can result in a better user experience. |
| Pre-requisites | MFA capability is available through IAM The service provider integrates with IAM for MFA whenever it needs to provide a challenge Appropriate policies are defined to force MFA when necessary |
| Supporting Member Companies | ForgeRock, Okta, Ping Identity |
