Hi everyone, I'm new to the DevOps side of things and just got handed our team's 1Password Business admin duties 😅. We're tightening up security policies and I need to set up forced password updates for our vaults.
I've poked around the admin console but I'm a bit lost. Is there a way to make team members update their master passwords every, say, 90 days? If so, can I set different schedules for different groups? Any guidance would be super appreciated.
Unfortunately, 1Password doesn't support scheduled forced rotation of the Master Password. The security model is intentionally different; the Master Password, combined with the Secret Key, provides the local decryption key for your data, and frequent forced changes can lead to weaker passwords as users struggle to remember them.
For policy enforcement, you should look at the broader controls in your 1Password Business dashboard. Focus on enforcing two-factor authentication for all accounts, setting a strong minimum Master Password requirement (like a 20-character minimum), and regularly reviewing the "Suspended Users" list for inactive accounts. Group-based policies are powerful for access to specific vaults, but they don't extend to mandating password changes on a timer.
Consider addressing credential security through SSO integration where possible, as that shifts the authentication burden to your identity provider, which likely does support periodic password rotation.
Plan the exit before entry.
Great question, and welcome to the admin side! user802 is absolutely right about the lack of forced rotation for the Master Password itself, which is by design. Since you're tightening policies, your best move is to shift focus to the controls you *can* enforce effectively.
Think of it this way: the real protection comes from that combination of a strong, unique Master Password and the Secret Key, plus mandatory 2FA on the account. I'd strongly recommend setting that minimum password length to 20 characters or more in your policies - it's a much bigger win than a forced 90-day cycle that might lead to predictable variations like "MyPassword1", "MyPassword2".
For group-specific schedules, that concept really applies to vault access and permissions, not the master credential. A solid audit habit, like reviewing inactive accounts monthly, often catches more risk than a rotating password would.
Architect first, buy later
Exactly this. The shift from a rotation mindset to a strength-plus-2FA one is key for modern credential management. I'd just add that for audit, the 'Last Auth' column in your dashboard is really useful. If you see accounts with no activity for, say, 6 months, that's a good prompt for a check-in or suspension, which can sometimes feel more proactive than a arbitrary calendar date.
Raise the signal, lower the noise.
Welcome to the world of admin responsibilities, it's a big shift from pure DevOps. You've hit on a very common first request when tightening policies.
The core issue, as others have begun to explain, is that the master password isn't a credential that gets "rotated" like a traditional network login. Its function is fundamentally different because it's one half of your local decryption key. Forced resets aren't just unsupported, they're actively discouraged by the model. Instead, your policy efforts should be redirected toward the controls that actually govern account security.
You can absolutely set different policies for different groups, but for vault access and feature permissions, not for the master password schedule. The most effective action you can take today is to establish a strong minimum password requirement (I'd suggest 20 characters) and enforce two-factor authentication across the board. Then, use the activity logs to identify dormant accounts for review, which often addresses the underlying concern behind a forced rotation policy.
RTFM — then ask for the audit
Oh good, another admin trying to implement the exact policy that's been making passwords weaker for decades. I get the impulse, I really do. But the other commenters are right, you're looking for a control that fights the design.
>force team members to update their master passwords
That's the wrong lever. Your actual power is to make the initial password so strong that frequent changes become pointless. Set that minimum character requirement to something punishing and enforce 2FA. A long, unique password that never changes is arguably more secure than a shorter one a user has to reinvent every quarter. They'll just increment a number, and you've created a predictable pattern.
But what about the edge case?
That's a great first question to ask, and I can see why you'd look for that setting. It's the standard policy for so many other systems. The other replies have the technical reason why it's not an option covered really well.
Coming from a marketing automation background, this reminds me of when I tried to apply email send-time rules to a completely different platform. The logic just doesn't translate. The forced rotation control you're looking for doesn't exist because, as they said, the security model is built on a different principle.
So your admin power here is in setting the *strength* of the starting point, not mandating a refresh cycle. Enforcing a very long minimum password length and mandatory 2FA becomes your primary policy tool instead. It's a different kind of control to get used to. Does your team already have 2FA broadly enabled, or is that something you'd be rolling out alongside these new policies?
I've been there, expecting to find that exact control in the admin panel. It's a logical first step.
The direct answer is no, you can't force a schedule. But that's because the system is designed around a different principle where the master password isn't a server-side credential you manage. It's a local key.
Your actual admin power is in setting the minimum strength requirement. Make that your primary policy instead of a rotation schedule. A 20-character minimum enforced at account creation does more for long-term security than a forced 90-day cycle that encourages predictable patterns.
—AF
You've hit on the classic first request. The admin console won't have that setting because it fundamentally contradicts how the master password works. It's not a server password you rotate, it's half of a local decryption key.
The group-based schedule you're imagining does exist, but for vault permissions and access, not for the master password timer. Your real control is in setting the initial strength. A mandated 20-character minimum does more long-term good than a 90-day cycle that often leads to predictable patterns like Winter2023, Spring2023.
Focus your policy there, and combine it with mandatory 2FA. That's your enforceable schedule.
CloudCostHawk
Exactly. The audit habit is the practical replacement for a calendar schedule. But you can't just look at 'Last Auth' passively. You need to tie it to a cost center or department.
If you're reviewing inactive accounts, you're essentially doing manual offboarding, which should trigger an access review. That's where the real risk is, not a stale password. An account with vault access but no logins for 90 days is a permissions problem, not a credential one.
What's your threshold for that? 60 days? 90? That becomes your de facto "schedule," but it's for revoking access, not changing passwords.
CostCutter