### Problem/Motivation The release audit of 2026-10-20 found six ways the vault's own protections can be bypassed or silently undone. - **A vault read can undo a passphrase protection.** `SubjectKeyManager::touch()` records activity by saving the whole subject-key record it loaded earlier in the request. When the owner turns passphrase protection on in another request meanwhile, the next read writes the old record back: the salt is emptied and the blob wrapped by the Master KEK alone returns. The vault is unprotected while the owner is told it is protected. The Master KEK rotation (`rewrapUnder()`, `rekeyInPlace()`) and the dormancy reminder (`DormancyCollector::warn()`) save whole records the same way. - **The passphrase check on the passphrase form is not throttled.** Removing protection asks for the current passphrase and runs an Argon2id derivation, with no limit. The unlock form limits the same check (`flood.unlock_limit`). Anyone holding the owner's session, an administrator signed in as the owner included, can guess the passphrase there without limit, and load the server's CPU. - **A trust given again after a refusal is not audited.** `TrustManager::trust()` records `pdv.trust.created` only for a new row. Turning a declined row into a trust, or changing a trust's expiry, changes what a service may read or write, and records nothing. - **The secret store can be reached over plain http.** `pdv_vault` sends the store token and every subject key to `$settings['pdv_vault']['address']` whatever its scheme. The vault connection on a consumer site requires https since #3620299, except loopback hosts and hosts allowed in settings.php. - **Passphrases are typed into a text field.** `PassphraseFieldTrait` builds a `type="text"` input and masks it with a disc font. A screen reader reads each typed character aloud, as it does for any text field, and a braille display shows it. A browser set not to load web fonts shows the passphrase in clear. - **A passphrase can be one character long.** `VaultPassphraseForm` asks only for a non-empty passphrase that matches its confirmation. The passphrase is what keeps an operator holding the Master KEK and a database dump out of the vault, and a short one falls to an offline guess at once. ### Proposed resolution - Write the activity, the reminder and the rotation of a subject key with an update of their own columns, conditioned on the row they read (`touch()`: one conditional `UPDATE`; rotation: only when the stored blob is still the one it re-wrapped, else the subject counts as failed and is retried next run). - Throttle the "remove protection" check with the unlock form's limit and counter. - Record `pdv.trust.created` when a declined row becomes a trust, and a new `pdv.trust.updated` when a trust's expiry changes. Add `updated` to the audit-trail bridge's catalog. - Move `HttpsPolicy` to the `pdv` contract module, with the allowed hosts passed in, and use it for the secret store too (`$settings['pdv_vault']['allow_http_hosts']`). - Require at least 12 characters for a new passphrase. - Build passphrase fields as `type="password"` and drop the disc font. A separate commit: it reverses the choice made to keep browsers from offering to save the passphrase. - Tests: each defect, proven to fail without its fix. ### API changes `Drupal\pdv_client\HttpsPolicy` becomes `Drupal\pdv\HttpsPolicy`. New audit action `pdv.trust.updated`. A secret store on plain http other than loopback must now be listed in `$settings['pdv_vault']['allow_http_hosts']`. Pre-1.0: no deprecation. AI-Generated: Yes (Claude Code was used to help draft this issue summary and will be used to write the change and its tests. I review both before the MR is opened.)