open-vault/website/content/docs/enterprise/mfa/index.mdx

---
layout: docs
page_title: MFA Support - Vault Enterprise
description: >-
  Vault Enterprise has support for Multi-factor Authentication (MFA), using
  different authentication types.
---

# Vault Enterprise MFA Support

-> **Note**: This feature requires [Vault Enterprise Plus](https://www.hashicorp.com/products/vault/).

Vault Enterprise has support for Multi-factor Authentication (MFA), using
different authentication types. MFA is built on top of the Identity system of
Vault.

## MFA Types

MFA in Vault can be of the following types.

- `Time-based One-time Password (TOTP)` - If configured and enabled on a path,
  this would require a TOTP passcode along with Vault token, to be presented
  while invoking the API request. The passcode will be validated against the
  TOTP key present in the identity of the caller in Vault.

- `Okta` - If Okta push is configured and enabled on a path, then the enrolled
  device of the user will get a push notification to approve or deny the access
  to the API. The Okta username will be derived from the caller identity's
  alias.

- `Duo` - If Duo push is configured and enabled on a path, then the enrolled
  device of the user will get a push notification to approve or deny the access
  to the API. The Duo username will be derived from the caller identity's
  alias.

- `PingID` - If PingID push is configured and enabled on a path, then the
  enrolled device of the user will get a push notification to approve or deny
  the access to the API. The PingID username will be derived from the caller
  identity's alias.

## Configuring MFA Methods

MFA methods are globally managed within the `System Backend` using the HTTP API.
Please see [MFA API](/api-docs/system/mfa) for details on how to configure an MFA
method.

## MFA Methods In Policies

MFA requirements on paths are specified as `mfa_methods` along with other ACL
parameters.

### Sample Policy

```hcl
path "secret/foo" {
  capabilities = ["read"]
  mfa_methods  = ["dev_team_duo", "sales_team_totp"]
}
```

The above policy grants `read` access to `secret/foo` only after _both_ the MFA
methods `dev_team_duo` and `sales_team_totp` are validated.

## Namespaces

All MFA configurations must be configured in the root namespace. They can be
referenced from ACL and Sentinel policies in any namespace via the method name
and can be tied to a mount accessor in any namespace.

When using [Sentinel
EGPs](/docs/enterprise/sentinel#endpoint-governing-policies-egps),
any MFA configuration specified must be satisfied by all requests affected by
the policy, which can be difficult if the configured paths spread across
namespaces. One way to address this is to use a policy similar to the
following, using `or` operators to allow MFA configurations tied to mount
accessors in the various namespaces:

```python
import "mfa"

has_mfa = rule {
    mfa.methods.duons1.valid
}

has_mfa2 = rule {
    mfa.methods.duons2.valid
}

main = rule {
    has_mfa or has_mfa2
}
```

When using TOTP, any user with ACL permissions can self-generate credentials.
Admins can generate or destroy credentials only if the targeted entity is in
the same namespace.

## Supplying MFA Credentials

MFA credentials are retrieved from the `X-Vault-MFA` HTTP header. The format of
the header is `mfa_method_name[:key[=value]]`. The items in the `[]` are
optional.

### Sample Request

```shell-session
$ curl \
    --header "X-Vault-Token: ..." \
    --header "X-Vault-MFA:my_totp:695452" \
    http://127.0.0.1:8200/v1/secret/foo
```

### API

MFA can be managed entirely over the HTTP API. Please see [MFA API](/api-docs/system/mfa) for more details.