How 1Password Tracks the Passwords It Generates
Every time 1Password creates a new password for you, it stores that previous value in a history list attached to the entry. This is different from version history, which tracks structural changes like edits to the title or notes field. Password history specifically preserves the cryptographic value of the password itself across generations. If you regenerate a password, the old one doesn't disappear from the vault. It stays there as a reference point. I work with a team that rotates credentials quarterly for compliance purposes, and we rely on this feature constantly. One thing most people don't realize is that password history only persists within the same vault entry. If you move a login item to a different vault, the history travels with it. If you copy the entry and paste it elsewhere, the new copy starts with a clean history slate. I learned that the hard way when a contractor duplicated a production database entry into a staging vault and lost three generations of rotated passwords in the process. They had to recreate them from scratch because the audit log couldn't trace back past the duplication point.
Understanding 1password Generated Password History
The history appears in the entry editor on desktop when you click the password field and open the dropdown menu. Each prior value shows with a timestamp and a note indicating whether it was user-generated or system-generated. The strongest password in the chain remains the active credential. 1Password keeps up to ten entries in that history by default, and you can't change that number from the UI. It's hardcoded. The API exposes this data through the history attribute on password-type fields. When you query an item via the CLI using 1password item get, the output includes a history array if one exists. You can pipe that into jq and export it as JSON for audit reporting without touching the GUI. That's how our compliance team pulls quarterly rotation reports. It takes about four minutes for a vault containing roughly 200 items. Without the CLI export path, it would take closer to two hours of manual screenshots. Here's a nuance beginners miss: editing the password field manually and then clicking generate again does not create a new history entry. Only a full regeneration via the generator interface increments the history. If you type a value by hand and save it, the previous generated value is overwritten silently. I caught this once when someone manually tweaked a service account password to match an older convention, then wondered why their rotation report showed a gap. The manual edit broke the chain entirely. The workaround is to always use the generator button even when making small character changes, because that preserves the lineage.
Another thing nobody mentions is that password history is scoped per device until it syncs. If you generate a password on your Mac, it appears in history locally immediately. Your iPhone won't show it in history until the vault sync completes, which usually happens within seconds but can take longer on congested networks or when the device has been offline for extended periods. I had a situation where a shared team member couldn't see the latest history entry on their iPad for about twelve minutes after I regenerated a credential on my workstation. The entry was correct, just not visible yet on that device. Waiting it out was the only real fix. There are limitations worth being blunt about. Password history does not support deletion from within the 1Password app. Once a password generation is recorded, it stays there until the item is deleted entirely. This is by design, but it means sensitive rotation chains can accumulate values you'd rather not have sitting in a shared vault. The only way to remove a historical password is to delete and recreate the entire login entry, which also destroys any associated TOTP tokens, secure notes, and custom field data. I've done this once for a compromised credential where the old password had been leaked, and the rebuild took about twenty minutes because of all the dependent integrations that needed reconfiguration. If you need granular control over what gets retained, the built-in history mechanism won't give you that. You're better off using 1Password's audit feature or exporting rotation logs externally and managing retention through your own policy. The built-in history is useful for tracing what changed and when, but it's not a compliance-grade audit trail on its own. For that, pair it with regular exports to your SIEM or document management system.
Get the Full Details
