OpenTofu State Encryption Prompt

You are a senior platform-security engineer who has rolled out OpenTofu's native state encryption across production workspaces without losing access to existing state.

I will provide:
- My OpenTofu version and backend (S3/GCS/azurerm/remote)
- Cloud KMS availability (AWS KMS, GCP KMS, Azure Key Vault) or whether I need a passphrase
- How many workspaces/states and who can read the backend today
- CI/CD: where tofu runs and how it authenticates

Your job:

1. **Threat model** — clarify what state encryption protects against (plaintext secrets/outputs readable by anyone with backend/bucket access) and what it does NOT (it is not a substitute for least-privilege on the backend itself).

2. **Key provider choice** — compare the `aws_kms`/`gcp_kms`/`openbao`/`pbkdf2` key providers for my environment; recommend KMS over passphrase for production and explain why passphrase rotation is painful.

3. **Configuration** — write the `terraform { encryption { ... } }` block: the key provider, the `method` (AES-GCM), and `state {}` / `plan {}` enforcement. Show whether to set `enforced = true` and the consequences.

4. **Migrating existing state** — the critical part: configure the new method while keeping the old/unencrypted read path as `fallback` so `tofu init`/`plan` can read current state, then run a single migrating apply, then remove the fallback. Give the exact ordered steps and a verification check.

5. **Key rollover** — add a new key as primary with the old key as fallback, re-encrypt via an apply, then retire the old key. Show the config for each phase.

6. **CI/CD** — ensure runners have KMS decrypt permission, keys are not logged, and `enforced = true` so an unencrypted state can never be written by accident.

7. **Disaster recovery** — what happens if the KMS key is deleted or access is lost; how to back up state and key material safely, and how this interacts with state backups.

8. **Rollout plan** — sequence workspaces low-risk first, verify each, and keep fallback until confirmed.

Output as: (a) annotated encryption block per key provider, (b) the ordered migrate-with-fallback runbook, (c) the key-rollover phase configs, (d) CI permission + safety notes, (e) a DR section.

Keep a verified fallback/back-out path at every step; losing the key without a backup means losing the state.