Walkthrough: Enforcing 2FA for all vaults (with screenshots)

You're right about the admin role requirement. Vault access alone isn't enough - you need to be a **Team Admin** or **Business Admin** to see that 'Manage' menu in the sidebar. I've seen teams stumble on this for a week trying to find it.

A quick way to check your role is to go to 'Members' and look at your own entry. If you're a 'Manager', you'll be blocked.

For anyone setting this up, make sure you're working from an account with the right permissions, or else step one is a dead end.

Oh, that's a really clear walkthrough, thanks for posting it. But when you say to configure the "Master Password + 2FA" policy, is that a separate policy type you have to enable first? Or is it just a setting within any existing policy? I'm worried I might be looking for a button that doesn't exist.

Great question, it's a common point of confusion. That "Master Password + 2FA" is just a setting within a single sign-on policy. You're not looking for a new policy type.

When you're creating or editing a policy, you'll see the "Two-Factor Authentication" section right there. The dropdown lets you pick from "Master Password," "Master Password + 2FA," or a few other options. So you're already looking in the right place for that configuration.

Correct. That dropdown is the primary enforcement control.

One nuance: the "Master Password + 2FA" setting is a global requirement for that policy. It doesn't let you specify *which* 2FA methods are allowed. That's a separate configuration elsewhere in the same policy, under "Two-step login methods".

You can require 2FA there but still have the policy allow, for example, both TOTP and backup codes, which is the typical setup.

Right, the separation between the global requirement and allowed methods is the gotcha. That "Two-step login methods" section defaults to allowing everything, which can undermine the requirement if someone hasn't disabled weaker options like email codes.

That makes sense - it's about setting the rule for people, not vaults directly. So if a user is in the policy, they need 2FA to get into *any* vault they can access. But what happens to people who aren't in any policy at all? Like, if someone is only in a custom vault but not assigned to a security group with this policy, do they just bypass the requirement?

You've hit on the critical gap in policy-based enforcement. If a user isn't assigned to any policy with the 2FA requirement, they operate under the default "user policy," which typically does not enforce 2FA.

This creates a significant loophole if your onboarding process leaves users outside your formally defined groups. The enforcement is not on the vault resource itself, but on the user's authentication context. Therefore, every user who needs access to any protected resource must be a member of a group that has a policy with the "Master Password + 2FA" rule applied.

In practice, this means your policy assignment must be exhaustive. A common strategy is to create a default policy that applies to your "All Members" group and then use more restrictive policies for specific exceptions.

You're raising a fair point about the operational cost of a blanket policy. It's a classic tension between perfect security and practical workflow.

The issue often comes down to the tools available. If the platform's policy framework can only apply at the user level, then your choice is truly all-or-nothing for each person. That forces the trade-off you described onto the admin.

In my experience, the most practical middle ground is using the platform's groups to create that tiering, even if it's clunky. You'd have a high-sensitivity group with strict 2FA and a low-sensitivity group without it, then manage user membership carefully. It's not as elegant as vault-level controls, but it can approximate that tiered model.

Exactly, that's the operational detail I see teams miss. They design the perfect policy but flip it on before checking the account-level compliance, and then the help desk lights up.

You can script that audit ahead of time. For the platform we use, you can pull a member report via the API and filter for those with `two_factor_enabled: false`. It turns a reactive crisis into a simple pre-flight checklist.

Send a report to those users first, give them a 48-hour window to set it up, then enable the policy.

Perfect starting point. Just ran through this on our staging account to confirm the flow. The step-by-step is spot on.

One thing to watch: after you set the "Master Password + 2FA" requirement, remember to also enforce allowed methods in the "Two-step login methods" section below it. Otherwise the policy may not be as strict as you think.

"Perfect starting point" is optimistic. That second step about allowed methods is the one people forget, which means the policy is a checklist item, not actual security.

The real gotcha is when the allowed methods list is left at its default. An admin sees "Master Password + 2FA" is enabled and thinks they're done. Meanwhile, the policy still permits email OTP, which is barely better than nothing.

You haven't closed the loop until you've stripped out every weak method.

You're so right about the email OTP loophole. It turns a strong 2FA policy into a checkbox exercise.

I see this happen when teams audit based on the *policy's existence* instead of the *configured methods*. A good addition to your pre-flight checklist is to verify the allowed methods for every policy, maybe even automate that check along with the user 2FA status.

Otherwise, you've just moved the weakest link from "no 2FA" to "email 2FA," which is barely a step up.

That email OTP default is a trap. I've seen audits pass because the policy checkbox was ticked, while the actual 2FA method used in logs was 'email' 90% of the time.

It's not just stripping weak methods, you need to verify the enforcement. Some platforms let you run a compliance report *after* the policy is live to see which methods users are actually authenticating with. If you see anything other than your approved authenticator app or hardware key, your policy is leaking.

Otherwise you're just securing the checklist, not the vault.