Asserted vs attested: two very different promises
A vault can require that its members protect their keys a certain way. But there are two kinds of "requirement" here, and telling them apart is the most important paragraph in this handbook.
| Asserted | Attested | |
|---|---|---|
| What happens | Your client declares how it is protecting your key, and signs that declaration | A hardware device proves, cryptographically, that the key material was created inside it and cannot be extracted |
| Stops carelessness? | Yes: the official client refuses to create a non-conforming key | Yes |
| Stops someone who lies? | No. Nothing can tell from the outside whether a file on your disk really has a passphrase | Yes. This is the only tier that enforces anything |
| Good for | Catching shortcuts and mistakes; giving auditors a signed artifact | An actual security boundary |
Policy values are called asserted-passphrase and attested, not "passphrase required" and "hardware required". The word asserted stays in the name everywhere, in the config, in the command output and in the audit log, so that nobody ever reads a report and believes a claim was verified when it was only stated.
One subtlety worth carrying with you, because it is easy to get wrong: a security key signs, it does not decrypt. Attestation proves the login key came from the hardware, which says nothing at all about the key that opens your vaults. Tying decryption to the device needs a specific extra device feature (hmac-secret), which the tool uses to derive an unlock key that cannot be exported. So in this system, "attested" means precisely: unlocking requires that physical device and a human touch. It does not mean the key never exists in your computer's memory. After unlocking, it does, for as long as the operation takes. That is true of every design of this shape.