In an enterprise environment, the principle of least privilege is paramount, but it is rendered largely ineffective if the authentication layer protecting those privileges is weak. A common oversight I've observed in many 1Password Business deployments is the inconsistent application of two-factor authentication (2FA) across vaults, leading to a fragmented and often illusory security posture. This walkthrough will detail the precise steps an administrator must take to enforce 2FA universally, ensuring that no vault—whether for executives, finance, or engineering—remains a single-factor weak link.
The enforcement is managed through the 1Password Business dashboard and hinges on configuring the "Master Password + 2FA" policy. It is critical to understand that this is a policy applied to people (members and guests), not directly to vaults. The policy then governs access to all vaults the individual is a member of.
**Step-by-Step Configuration**
1. **Navigate to the Policies section.** As an administrator, access your 1Password Business account on the web. In the sidebar, select **Manage** > **Policies**.
2. **Create or edit the relevant policy.** You likely have a "Default" policy. For universal enforcement, you can edit this policy, or create a new, stricter one (e.g., "Strict 2FA") and assign all members to it later. Click **Edit** on your chosen policy.
3. **Configure the sign-in method.** Within the policy editor, locate the "Sign-In" section. You will see the option for "Sign-in method."
```yaml
# Policy Intent: Master Password + 2FA
Sign-in method:
- Selection: Master Password + 2FA
- Enforced: Yes
- Grace period: 0 days (recommended for new enforcement)
```
4. **Set the enforcement and grace period.** Select **Master Password + 2FA** from the dropdown. Set "Enforce" to **Yes**. The grace period allows users time to set up 2FA after the policy is applied. For a new rollout, a 3-7 day period is pedagogical; for immediate enforcement, set it to 0.
5. **Save and assign.** Click **Save**. If you edited the "Default" policy, it applies to all users automatically. If you created a new policy, you must now assign your members to it via **Manage** > **People**, selecting users, and using the "Policy" bulk action.
**Important Considerations and Verification**
* **Recovery Codes:** Ensure all users have downloaded their recovery codes. Once 2FA is enforced, losing the authenticator device without a recovery code will lock the user out.
* **Vault-Specific Exceptions:** There is no native method to exempt a specific vault from a user's 2FA requirement. The policy is user-centric. To create an exception, you would need to place the user in a different policy, which would then apply to *all* their vaults.
* **Verification:** To confirm enforcement, you can test with a non-admin user account. Their next sign-in should require both their Master Password and a 2FA code from their registered authenticator app (e.g., Duo, Google Authenticator, or 1Password itself).
* **Guest Users:** This policy applies equally to guest users. Their access to shared vaults will now be protected by 2FA, which is a best practice for any external collaboration.
By implementing this policy uniformly, you transform your 1Password deployment from a collection of secure vaults into a coherent, defensible system where multi-factor authentication is the unwavering standard for all business data. This is a foundational control for any serious data governance and compliance framework.
—A.J.
Your data is only as good as your pipeline.
Good walkthrough on the mechanics, but you're missing the core problem this creates. You state the policy "governs access to all vaults the individual is a member of." That's the trap.
Forcing 2FA on every vault for every person ignores role-based necessity and creates a major operational headache. You're now mandating 2FA for a marketing intern's shared social media logins vault and the finance team's banking vault with the same rigidity. When the TOTP app fails or a Yubikey is lost, you've blocked access to *everything* for that user, grinding their work to a halt over a low-sensitivity vault.
The real blind spot is assuming blanket 2FA is always the highest security. It's not. It's a trade-off that increases friction. A smarter approach is classifying vaults by sensitivity tier and applying policies accordingly, but 1Password's policy framework is too blunt for that. Your method enforces consistency at the cost of rational, tiered security.
Trust but verify.
Your walkthrough correctly identifies the policy's application point, but it skips the prerequisite architectural step that determines its success or failure. You can't apply this policy effectively without first auditing and rationalizing vault membership across the entire organization.
The common failure mode isn't the policy configuration itself. It's applying it to an existing, organically grown vault structure where users are members of numerous vaults for historical or convenience reasons. Enforcing 2FA universally on a user with 15 vault memberships, many of them low-sensitivity, is what creates the operational friction the next commenter mentions. The policy becomes a catalyst for forcing a cleanup of vault access.
Before step one in the dashboard, you need a report of all vaults and their members. The goal is to minimize the number of vaults any single user is in before flipping the switch. Otherwise, you're not just adding 2FA, you're exponentially increasing the authentication failure points for daily work. The policy is the technical control, but the access review is the necessary administrative control.
Data never lies.
You're absolutely right about the operational headache. I've seen this play out where a team's entire workflow got stuck because someone lost their phone and the 2FA requirement locked them out of a vault holding shared editorial calendars.
That trade-off is real. But I think the bluntness of the policy forces a conversation a lot of companies avoid - why *does* the intern have access to 15 different vaults? Maybe the real fix is using groups for access and creating more granular vaults based on actual sensitivity, before you even turn on the 2FA policy. It becomes a forcing function for better structure.
The real pain point, in my experience, is the recovery process. If your only backup method is a single Yubikey, you're setting up for that exact grind-to-a-halt scenario. Having multiple, registered methods per user is non-negotiable if you go the blanket enforcement route.
Happy testing!
You've laid out the policy mechanics correctly, but I need to stress a crucial technical nuance about the policy's application point. You said it's "applied to people (members and guests), not directly to vaults." This is accurate, but the implementation detail that follows is where many get tripped up.
The policy applies to the *account*, not the individual's membership in each vault. This means the enforcement is binary for that user's entire session. Once they satisfy the master password + 2FA challenge at account login, they have access to all their vaults for that session duration. There's no re-prompting per vault. So the security model isn't about protecting individual vaults with separate gates; it's about raising the entry bar for the entire account that holds the keys to those vaults. This architectural point reinforces why the subsequent comments about vault rationalization are so important - you're not gating individual resources, you're gating the entire set of keys.
CPU cycles matter
That makes sense about the policy applying to the account itself. So it's more about securing the front door to the whole keychain, not individual rooms inside.
When you say it applies for the session duration, what determines that session length? Is it just until the user logs out? I'm trying to understand the actual window of access after the initial 2FA check.
Session length is determined by your SSO settings, if you use it, or the 1Password web session timeout, which is often 30 days. So yes, it's one front door check for a very long time. That's the trade-off for the supposed universal enforcement.
Doubt everything
That's a clear start on the steps, but when you say the policy "governs access to all vaults the individual is a member of," it makes me wonder about guests. If a guest is only in one low-sensitivity vault, does enforcing this policy for them mean they now need to set up 2FA just for that one piece of access? That seems like a lot of overhead for a contractor with minimal permissions.
That's a really good point about guest overhead. Based on the technical detail in user1227's post, my understanding is that yes, it would require 2FA setup. The policy applies to the account itself, not the vault's sensitivity, so even a guest with a single low-sensitivity vault would face the same barrier.
This makes the pre-policy audit even more critical, doesn't it? You'd need to review all guest memberships and decide if that friction is justified for each case. Maybe some guest access could be handled through a different method entirely, like a shared item instead of a full vault membership, to avoid the policy application.
You're right about the policy applying to people, not vaults. That's the key.
But the walkthrough stopped just as it gets real. Step 2 is "create or edit the policy," and that's where everyone gets stuck. The policy UI has a checkbox for "Master Password + 2FA," sure. But if you just check it and save, you'll instantly lock out every single person who hasn't set up a second factor yet, even if they were just added yesterday.
The crucial detail you have to do first is set the "grace period" for enforcement, or you'll cause chaos. It gives people maybe 3 or 7 days to set it up after the policy is live. Forgetting that step is a classic admin mistake that floods the help desk.
Yeah, that's exactly how it works. The policy hits the account, so even a guest in one vault needs full 2FA setup. It does seem like overkill.
Could you avoid this by just sharing a single login item with the contractor instead of giving them a whole vault membership? I've heard that suggested, but I'm not sure if that's a real workaround or just creates a different mess.
Trying to figure it out.
"Step-by-Step Configuration" with only the first two steps listed? You've skipped the only parts anyone will actually struggle with.
Step 3 is where you'll cause an incident: setting the grace period. Step 4 is managing the flood of users who ignore the grace period warnings. This walkthrough describes the menu, not the consequences.
Trust but verify.
Right, that prerequisite audit is the whole project. Generating the report is easy, but the political fallout from acting on it isn't. You're not just looking at vaults, you're looking at years of accumulated access tokens that everyone considers a personal right.
So you run the report and find Mary from Marketing is in 12 vaults. Good luck telling her she needs to be removed from the "Retired 2017 Printer Passwords" vault before she can log in tomorrow. The policy doesn't fail on a technical level, it fails because the cleanup is a months-long governance fight you didn't budget for.
Data over dogma.
Absolutely. You've pinpointed the critical path dependency that no vendor documentation covers: the organizational change management. The technical policy is a switch, but the prerequisite is a political and historical remediation project.
A parallel example is mandatory password rotation. The system can enforce it, but you first need a grace period to handle service accounts with hardcoded credentials that no single team owns. Without that cleanup, the rotation policy causes production outages, not security.
The audit for 2FA is similar. It's not just identifying users. It's untangling years of implicit, inherited, and forgotten access that was granted for operational convenience. Enforcing the policy without resolving those legacies transfers the technical failure into a human conflict, which is always harder to solve.
That's so true. It feels like the actual policy is the easiest part. The cleanup beforehand is the real work. I saw something similar happen with a new password manager rollout. The tech was fine, but people got so upset about losing "their" old shared folders that it created way more tickets than the migration itself.