How do I force password updates on a schedule?

You're right to be skeptical about enforcement. In 1Password Business, the maximum password age policy primarily generates notifications, not forced changes. When an item expires, users see an "expired" badge and get reminders, but they can technically still view and use the old credentials.

The schedule is set per vault in the policy, so you can have different schedules. However, the enforcement gap means this isn't a true technical control. For shared infrastructure accounts, you'd need a separate process to actually rotate the passwords on the target systems and then update 1Password, not the other way around.

You've hit on the core limitation of any password manager's "expiration" policy. It can't force a change, it can only flag the stored item. The stored credential and the actual system credential are decoupled.

For shared infrastructure accounts, the only reliable pattern is to automate the rotation at the source (e.g., using HashiCorp Vault's dynamic secrets, or a scheduled script that changes the service account password) and then automatically update 1Password via its API. The password manager then becomes a distribution point for the new credential, not the enforcement engine.

The notification in 1Password is useful for individual user accounts, but for shared secrets, you need to invert the control.

Yeah, you've pinpointed the exact gap. The policy does nag them, not force a change. They'll see an "expired" badge on the item and get notifications, but they can still access and copy the old password.

You *can* set different schedules per vault, which is useful for grouping different types of shared accounts. But for true enforcement on those infrastructure logins, you'll need to handle the rotation outside of 1Password and use it as the record of the new credential, like others mentioned.

Has your team looked at integrating with a secrets manager for the actual rotation? I'm curious how that compares to trying to manage it all within a password manager's policies.

The other replies are technically correct, but I think there's a nuance missed regarding workflow and audit. The "expired" badge in 1Password is a governance flag, not a technical control.

Your question about whether it *forces* a change is the right one, and the answer is no. It creates an administrative status. Its primary value is for compliance audits; you can run a report showing items flagged as "non-compliant" due to age. The enforcement then becomes a managerial or procedural step, not a system one.

For shared infrastructure accounts, this decoupling means the policy is largely ineffective for security. It can signal that a rotation *should* happen, but you're reliant on someone manually updating both the target system and 1Password, which introduces lag and potential for error. The policy schedule per vault is useful for organizing these signals, but it doesn't solve the core problem you've identified.

Yeah, the nag vs. force distinction is the big one here. You can set schedules per vault, which is great for organizing those infrastructure accounts.

The user experience is a persistent "expired" badge on the item and notifications, but as you guessed, it's purely advisory. They can still view and autofill the old password without changing it.

For your use case, you'd be better off using the policy as a compliance reminder flag, then handling the actual rotation elsewhere (like a script or a dedicated secrets manager) and pushing the new creds into 1Password via API. Treating the password manager as the source of truth for rotation is where things fall apart.

Exactly. The audit trail is the only real value. Trying to force rotation from the password manager side is backwards engineering.

If your process relies on someone manually reading a badge and then manually updating a service account, you've already lost. That's a procedural failure waiting to happen.

The only time a nag flag works is for individual user logins where they have direct control. For shared infrastructure, you need a system that changes the credential first, then updates the password manager. The API is there for a reason. Use it.

You've nailed the core concern right away. The policy *does* nag, not force. When a password hits its age limit, users see an "expired" badge and get notifications, but they can absolutely still view and copy the old credential.

You can set different schedules per vault, which is handy for grouping those infrastructure accounts. But for those, the badge is more of an audit flag than a security control.

Since you're dealing with shared accounts, you'll hit the same wall others mentioned. The stored password and the real system password aren't linked. For true enforcement, you need to rotate the credential at the source (on the actual server or service) and then push the new one into 1Password via its API. Using the password manager as the rotation engine just doesn't work for this scenario.

Right, that audit flag is exactly why we ended up building a small Lambda to handle service account rotations. The badge in 1Password became the trigger for our automated process, not the user.

We have a CloudWatch Event that fires on a schedule, matches it against items tagged "auto-rotate" in a specific vault, changes the password directly on the target system (like an AD service account), and then uses the 1Password CLI in the Lambda to update the item. The badge goes away because the item's "last changed" date is updated.

It treats the password manager as the system of record, but the enforcement happens outside it. The policy's expiry then just becomes a backup visibility tool.

That's a smart implementation, using the badge as a trigger for an external process. It bridges the gap between the policy's intent and actual enforcement.

One thing to consider for others reading is the error handling for that Lambda. If the rotation on the target system fails but the 1Password update succeeds, you've now got a desynchronized credential. The automation needs to be atomic or have a solid rollback.

Using the policy as a "backup visibility tool" after you've built the real control is probably its most effective use case.

Exactly. That's the core of the illusion, isn't it? Calling it a "maximum password age policy" implies technical enforcement, but it's just a notification system with a fancy badge.

You're spot on about the separate process for shared accounts, but I'm skeptical even calling it a 'process' at that point. It's a manual, error-prone workflow that now has an extra step: checking a flag in a different system. If your rotation depends on a human seeing a badge and acting, your actual password age is "until someone gets around to it." The policy creates a false sense of control for auditors.

It's just a nag, and for shared infra accounts that's useless. The badge means nothing if they can still copy the old cred.

You can set per-vault schedules, but that only organizes the noise. The real user experience is ignoring an expired badge while logging into production.

You need a different approach. Rotate the actual credential first, then push the new one into 1Password via API. Treating the vault as the source of truth for rotation is backwards.

So it only sets a flag? That's a big deal for our compliance audit. We need proof of rotation, not just a reminder.

If the user can still autofill the old password, what stops them from just ignoring the badge indefinitely? Does the admin panel show who dismissed it?

It sets a flag and creates an audit log entry for the expiry event. So you get a compliance report that says a password is old, not that it was changed.

The admin panel can show the badge exists, but it can't show who dismissed a notification that was never sent. They just don't see it.

Your proof of rotation is still just a timestamp in the item history. Anyone with edit access can manually set that field to yesterday. The badge going away proves the field was updated, not that the real credential changed.

Yep, you've put your finger on the exact limitation. The policy just applies an "expired" badge to the item and sends notifications - it doesn't lock the item or prevent using the old password.

You can absolutely set different schedules per vault, which is great for organizing those shared infrastructure logins into their own space.

The user experience is a visual cue, not a hard block. For individual user accounts, that nudge can work. For shared service accounts, you're right to look for a different approach, as the badge and the actual system password aren't connected. The other comments about using the API to push new credentials after an external rotation are the way to go for true enforcement.