## Problem A config dependency is not a protection. It declares that the dependent is *affected* when the config it names goes away, and Drupal resolves "affected" as **deletion** unless the dependent says otherwise: `ConfigEntityBase::preDelete()` deletes every dependent whose `onDependencyRemoval()` does not keep it. `PdvVaultConnection::calculateDependencies()` declares both referenced Keys, and its docblock reads the resulting cascade as the safe outcome: > Each referenced key module Key (the OAuth client secret, and the optional handle-encryption key) is declared a config dependency. That makes the key export alongside this connection and, crucially, makes the key's delete form warn that this connection depends on it (and removes the connection if the key is force-deleted) rather than leaving a connection silently pointing at a missing secret. So deleting either Key deletes the `pdv_vault_connection`. For `client_secret_key` that costs recreatable configuration. For `handle_secret_key` it costs data. ## Why the handle key is different `HandleStore::getCipherKey()` derives the at-rest key for stored vault handles from the connection: ```php $key_id = $connection->getHandleSecretKeyId(); $key = $this->keyRepository->getKey($key_id); $secret = $key !== NULL ? (string) $key->getKeyValue() : ''; return hash_hkdf('sha256', $secret, SODIUM_CRYPTO_AEAD_XCHACHA20POLY1305_IETF_KEYBYTES, self::HKDF_INFO . $connection_id); ``` Handles are stored in `user.data` under a name built from the connection id, so the **connection id survives** the connection's deletion and the HKDF `info` input is recoverable. What does not survive is which Key entity the connection named. That mapping exists only on the connection. The result of deleting the handle Key, which an operator might do while rotating or tidying keys: 1. The Key's bytes go, which is expected and is why you would restore from backup. 2. The cascade also deletes the connection, which is not expected. 3. Restoring the Key from backup is then not enough: nothing on the site still says which Key id that connection used, so the operator has to remember the pairing to make the stored handles decryptable again. Every stored handle stays in `user.data` as ciphertext the whole time. `getCipherKey()` throws *"Handle encryption key ... is missing or empty"* rather than silently falling back to plaintext, which is right, but the connection it names is gone too. ## The fix The dependency declaration stays: it is what the relationship is, and config export ordering, config diffs and the Key's delete form all read it. What it no longer means is "delete me too". - `onDependencyRemoval()` marks the departing Key and keeps the connection, whichever of the two is going. Keeping it over the client secret matters too: the connection is the only record of the handle key pairing. - `calculateDependencies()` stops declaring a Key whose deletion is in flight. Core re-runs it after `onDependencyRemoval()` returns TRUE and deletes the entity anyway if it still names the departing dependency, in `ConfigManager::getConfigEntitiesToChangeOnDependencyRemoval()`. - `preSave()` refuses outright when the departing Key is `handle_secret_key`, which is the middle proposed above. Reached from the UI, from `drush` and from any other caller, because the storage handler is where they all end. - A `key_delete_form` alter in `pdv_client` says why before the operator confirms, in the shape `Drupal\pdv\Hook\KeyDeleteFormHooks` already uses on that form for a Master KEK. Deleting the client secret Key stays allowed, and core already lists the connection on that form under *Configuration updates*. The two mechanisms noted above as looking right and not being (`hook_key_predelete()`, `hook_key_access()`) are why the refusal sits where it does, and a throw from `onDependencyRemoval()` would white-screen the delete form's dry run. `docs/cross-site-setup.md` now documents the handle encryption key and both outcomes; the `calculateDependencies()` docblock no longer describes the cascade as the protective outcome. **Folded in, unrelated:** `VaultTokenProvider` tested `is_array($data)` a second time after a throw that has already settled it. It is what turns the `phpstan` lane red as of today, green on `169da86` only because that ran an older phpstan, which was confirmed by running the same analysis against a pristine `1.x`. Its own commit, and it deserves its own release-notes line. --- AI-Generated: Yes (Claude Code was used to help investigate and draft this issue, and to implement it. The behaviour described was traced in `PdvVaultConnection::calculateDependencies()`, `HandleStore::getCipherKey()` and core's `ConfigEntityBase`/`ConfigManager`; the equivalent fix is implemented and tested in audit_trail #3620381.)