1Password BackerUpper — Because Your Password Manager Doesn't Back Itself Up

I use 1Password for everything. Personal credentials, infrastructure secrets, client project vaults, service account tokens — all of it lives in 1Password.

That’s a problem. 1Password is a SaaS product. If the account gets compromised, if there’s a billing issue, if someone with admin access does something catastrophic — there’s no “restore to yesterday” button. 1Password doesn’t offer tenant-level backup and restore. You’re trusting that the service will always be there, always be intact, and always be accessible.

For personal use, that’s probably fine. For a business running on it, that’s a gap in your BCDR posture.

So I built 1Password BackerUpper — an automated backup tool that exports every vault, encrypts the output with hybrid AES-256 + CMS encryption, and runs on a daily schedule. It’s open-source, MIT licensed, and has zero third-party dependencies beyond the 1Password CLI.

The Problem

1Password Business gives you a lot of control. Vaults, groups, service accounts, fine-grained permissions. What it doesn’t give you is a way to export and back up your entire organisation’s vault data in an automated, encrypted, auditable way.

The built-in export is manual. One vault at a time. Unencrypted. No scheduling. No integrity verification. If you’re running a business with 20+ vaults across multiple teams, that’s not a backup strategy — it’s a checkbox exercise.

What I wanted was simple:

• Automated — Runs daily without human intervention
• Complete — Every vault, every item, every document attachment
• Encrypted at rest — Not just a zip file sitting on a server
• Separation of concerns — The backup server should be able to create backups but not read them
• Auditable — Logs, integrity hashes, and a clear chain of custody

How It Works

The tool is a set of PowerShell scripts that orchestrate the 1Password CLI (op) to export vault data, then encrypt and store the output.

Here’s the flow:

1. A Windows Scheduled Task fires daily at 2AM
2. The backup script authenticates to 1Password using a service account token (stored with DPAPI encryption — only decryptable by the same Windows user on the same machine)
3. Every accessible vault gets exported as JSON, with document attachments pulled separately
4. The export is compressed into a zip archive
5. The archive is encrypted using a hybrid scheme: AES-256-CBC encrypts the data, then the AES key is wrapped in a CMS/PKCS#7 envelope using a certificate’s public key
6. A SHA-256 hash sidecar is written alongside the encrypted archive
7. Temp files are securely wiped (random overwrite, then delete)
8. Backups older than the retention window get pruned

The output is a single .zip.cms file per run, plus a .sha256 integrity hash.

The Encryption Model

This is the part I’m most particular about. The encryption uses a hybrid approach that solves a specific operational problem: the backup server must not be able to decrypt its own backups.

Here’s why that matters. If the backup server is compromised, the attacker has access to the backup files. If those files are encrypted with a key that’s also on the server, you’ve achieved nothing. The encryption is theatre.

The solution is asymmetric key wrapping:

• A self-signed Document Encryption certificate is generated once during setup. The .cer (public key) goes into the Windows certificate store on the backup server. The .pfx (private key) goes into a physical safe. It never touches the server.
• Each backup generates a random AES-256 key. The vault data is encrypted with that key using CryptoStream — constant memory, no file size limit.
• The AES key is then wrapped in a CMS envelope using the certificate’s public key.
• To decrypt, you need the .pfx from the safe. Without it, the .zip.cms file is cryptographically inert.

Secret	Where It Lives	Who Can Access It
Vault data	Encrypted .zip.cms archives	Requires .pfx private key
AES-256 key	CMS envelope inside each archive	Requires .pfx private key
Certificate private key (.pfx)	Physical safe only	Never stored digitally
Certificate public key (.cer)	Windows cert store	Can encrypt, cannot decrypt
Service account token	DPAPI-encrypted file	Same user + same machine only

The backup server can create encrypted archives all day long. It cannot open a single one of them.

The Vault Coverage Problem

Here’s something that surprised me during development: 1Password service accounts don’t auto-inherit access to new vaults. When someone in your org creates a new vault, the service account doesn’t know about it. Your backups silently stop covering it.

Worse, you can’t modify a service account’s vault access after creation. The only fix is to create a new service account with the updated vault list, store its token, and delete the old one.

I built two scripts to handle this:

• Test-VaultCoverage.ps1 — Compares what the service account can see against what the org actually has. Flags gaps.
• Sync-VaultAccess.ps1 — Detects missing vaults, creates a new service account with full coverage, stores the token automatically, and verifies access. Supports -WhatIf for a dry run.

This is the kind of operational gap that doesn’t show up in a README but absolutely burns you in production. Your backups look fine — they run, they produce files, the logs say “success.” But three months later you realise the Finance vault was never included because it was created after the service account.

Restore

Backups are worthless if you can’t restore from them. The restore script handles two modes:

Extract only — Decrypt the archive and dump the contents to disk for review. No changes to 1Password.

.\scripts\Restore-1Password.ps1 `
    -ArchivePath "C:\Backups\1Password\BCDR_1PW_20260309_020000.zip.cms" `
    -PfxPath ".\BCDR_1PW_Backup_Key.pfx"

Full restore — Decrypt and push items back into 1Password, either to original vaults or a dedicated DR recovery vault.

.\scripts\Restore-1Password.ps1 `
    -ArchivePath "C:\Backups\1Password\BCDR_1PW_20260309_020000.zip.cms" `
    -PfxPath ".\BCDR_1PW_Backup_Key.pfx" `
    -Restore -TargetVault "DR-Recovery"

The recovery runbook includes manual decrypt instructions for the scenario where the scripts themselves aren’t available. If you can get to a machine with PowerShell and the .pfx, you can recover.

Why PowerShell, Why Not Python/Go/Rust

Fair question. Three reasons:

1. The target platform is Windows. DPAPI, Windows Certificate Store, Windows Task Scheduler — these are native Windows APIs. PowerShell talks to all of them without additional libraries.
2. Zero third-party dependencies. The only external dependency is the 1Password CLI itself. No pip packages, no npm modules, no compiled binaries to manage. The attack surface stays minimal.
3. PowerShell 5.1 ships with every Windows install. No runtime to install, no version to manage, no PATH issues. It just works on any Windows 10+ or Server 2019+ machine out of the box.

Getting Started

The setup is a six-step process:

# 1. Clone
git clone https://github.com/Moffcorp-Labs/1Password_BackerUpper.git
cd 1Password_BackerUpper

# 2. Generate the encryption certificate
.\scripts\New-BackupCertificate.ps1

# 3. Configure
Copy-Item config\backup-config.example.json config\backup-config.json
# Edit backup-config.json — set CertificateThumbprint and BackupPath

# 4. Store the 1Password service account token
.\scripts\Initialize-Credential.ps1

# 5. Validate
.\scripts\Backup-1Password.ps1 -DryRun -Verbose

# 6. Install daily schedule
.\scripts\Install-ScheduledTask.ps1

The full setup guide in the repo walks through service account creation, certificate handling, and the first backup validation in detail.

Why Open-Source This

I built this for my own infrastructure first. But the problem isn’t unique to me — anyone running 1Password Business has the same gap. There’s no official backup tooling, and the alternatives I found were either unencrypted export scripts or paid third-party platforms that introduce their own trust dependencies.

The tool is MIT licensed. If you’re running 1Password Business and you don’t have automated backups, you should either use this or build something equivalent. The specific implementation matters less than closing the gap.

A password manager with no backup is a single point of failure for your entire credential infrastructure. And single points of failure are what BCDR planning exists to eliminate.

Check it out: github.com/Moffcorp-Labs/1Password_BackerUpper