# Error: passphrase must be the same as the last time the stack was updated

## TL;DR
You changed `PULUMI_CONFIG_PASSPHRASE` after the stack was created. The passphrase is baked into the state's encryption and cannot be rotated in place. Restore the old passphrase, or destroy and recreate the stack with the new one.

## The error

```
error: passphrase must be the same as the last time the stack was updated
```

## Fix it

1. Put the original passphrase back: `export PULUMI_CONFIG_PASSPHRASE='[original passphrase]'`.
   - Success check: `pulumi preview` works again.
2. If you must move to a new passphrase, plan a migration: `pulumi stack export` with the old passphrase to back up.
   - Success check: you have a restorable backup.
3. `pulumi destroy --yes`, then `pulumi stack init` a fresh stack (or re-init) with the new passphrase, and `pulumi up`.
   - Success check: the new stack encrypts with the new passphrase from birth.
4. Update every place the passphrase is stored (CI secrets, vault, team docs) so nobody reintroduces the old one.
   - Success check: all environments use the one current passphrase.

## When to use this
You hit this after changing `PULUMI_CONFIG_PASSPHRASE` on an existing passphrase-encrypted stack.

## When NOT to use this
Do not use this for a *missing* passphrase (`passphrase must be set with ...`). That is unset, not changed; just set it.

## Compatibility
Pulumi CLI 3.x, passphrase secrets provider, self-managed backends.

## Variants
- The same failure surfacing as a secrets-manager construction error mentioning the passphrase mismatch

## Root cause
The data key that encrypts state is derived from the passphrase at stack creation. There is no re-key operation: a different passphrase derives a different key, which cannot decrypt the existing state.

## Edge cases
- `pulumi change-secrets-provider` migrates *between providers* (e.g. passphrase to KMS), not between passphrases.
- If the old passphrase is lost entirely, the encrypted secrets in state are unrecoverable. Non-secret resources can still be adopted into a new stack via import.