Description: Privileged accounts are accounts that have special rights (e.g. admin rights) or are regular user accounts but are more sensitive because of the high impact in case of breach (e.g. CEO account). All these privileged accounts must be protected through strong authentication (MFA) to minimize the likelihood of breach. This protection has to happen during one of three stages:
- On first login to an account that is considered privileged
- After login, when accessing a resource (e.g. VM, server, etc.) that is considered of high value and therefore has to be protected.
- During a previously authenticated session, when issuing a command that is considered to have an elevated level of privilege. For example, an admin command to install software or launch a VM, or add/remove a user.
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.
Watch the deep dive webinar to learn more about this security outcome.
Implementation Approaches
- Self-contained Agent-based MFA
- Delegated MFA Using an External Identity Provider
- Delegated MFA and AM Using an External Identity Provider
- Just-In-Time MFA and AM
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.
| Title | Self-contained agent based MFA |
| Technology Components | Multi-Factor Authentication (MFA) Privileged Access Management (PAM) |
| Description | The MFA capability is tightly integrated with the solution that offers privileged access. For example, a PAM vendor can also offer MFA either as integral part of its own offering, or as an added (third-party) MFA software installed with the parent PAM offering. In both cases, privilege account protection (PAM) and MFA are 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 in PAM Appropriate policies are defined to force MFA when necessary |
| Supporting Member Companies | BeyondTrust, Centrify, CyberArk, Remediant, Thales, ThreatMetrix, VMware WorkspaceONE |
| Title | Delegated MFA Using an External Identity Provider |
| Technology Components | Access Management (AM) Privileged Access Management (PAM) |
| Description | In this approach, the MFA capability is loosely integrated between the solution that offers privileged access, and an external Identity Provider. For example, a PAM 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: 1. Federated model using SAML 2. Federated model using OIDC 3. Non-federated model using RADIUS In all cases, privileged access is granted only after a successful MFA response from the Identity Provider. |
| Pre-requisites | MFA capability is available through IAM PAM integrates with IAM for MFA whenever it needs to provide a challenge Appropriate policies are defined to force MFA when necessary |
| Supporting Member Companies | BeyondTrust, Centrify, CyberArk, ForgeRock, Okta, Ping Identity, Remediant, Thales, ThreatMetrix, VMware WorkspaceONE |
| Title | Delegated MFA and AM using an external Identity Provider |
| Technology Components | Multi-Factor Authentication (MFA) Privileged Access Management (PAM) |
| 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 solution that offers privileged access, and an external Identity Provider. For example, a PAM 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: 1. Federated model using SAML 2. Federated model using OIDC 3. Non-federated model using RADIUS In all cases, privileged access is granted only after a successful MFA response from the Identity Provider. The IdP may bypass actual MFA with user, if the policy allows it. For example, if an MFA was successfully done with user a short while ago, a subsequent request for MFA may be silently accepted and returned privileged service provider without involving the user. This can result in a better UX flow. |
| Pre-requisites | MFA capability is available through IAM Rather than implementing the MFA trigger logic in PAM, it is federated authentication from IAM where needed. During authentication, IAM will challenge user through its own MFA capability. Appropriate policies are defined to force MFA when necessary |
| Supporting Member Companies | Centrify, CyberArk, ForgeRock, Okta, Ping Identity, Thales, ThreatMetrix, VMware WorkspaceONE |
| Title | Just-In-Time MFA and AM |
| Technology Components | Multi-Factor Authentication (MFA) Privileged Access Management (PAM) |
| Description | In this approach, the PAM tool first authenticates the administrator via MFA. This could use a built-in MFA capability, or leverage the enterprise’s standard MFA solution via SAML or other integration method (RADIUS, etc.). Next, the administrator selects the asset (computer, etc.) on which they need privileged access. An Entitlement Check is performed to verify that the administrator is authorized to be allocated temporary privileged access on that asset. Assuming the Entitlement Check is positive, the PAM tool allocates the desired privileges (on the selected asset(s)) to the administrator’s account. At the conclusion of the activity, the privileges are automatically or manually revoked. In all cases, privileged access is granted only after a successful MFA response from the Identity Provider. Management of the Entitlements (used in the Entitlement Check) may be performed within the PAM tool, via an Access Management (AM) tool, or via a hybrid approach. |
| Pre-requisites | Centralized authentication to perform first step authentication Integration with an IdP component that can do MFA, and also use policy based trigger for involving user (for MFA) |
| Supporting Member Companies | BeyondTrust, Centrify, CyberArk, Remediant, Thales, ThreatMetrix, VMware WorkspaceONE |
