[HackTuah]

Slice 025 shipped with sealing off for every class and a note that the choice was the deployment's. That was a decision deferred rather than made. Researching it gives a different answer, and a per-class one.

What the standards actually say

source	bearing
CISA secure-by-design	the secure configuration should be the baseline, and deviating from it should be deliberate
NIST SP 800-171 3.13.16	CUI at rest must be protected; data needs encrypting once, and full-disk encryption on the endpoint is the ordinary implementation
NIST SP 800-171 3.13.11	requires a FIPS-validated module, not merely an approved algorithm — and 3.13.16 inherits it
NIST SP 800-53 SC-12(1)	maintaining availability of information when keys are lost is a control in its own right

Three consequences. Layering application sealing over an encrypted volume does not satisfy the at-rest control twice — it protects a different threat. This project's crypto is validated only on the FIPS leg, so sealing here is not a CUI at-rest control and must not be mistaken for one; the volume is. And with escrow and recovery explicitly out of this slice's scope, SC-12(1) bounds how far a default should reach.

The defaults that fall out

class	sealed by default	why
staged skill changes	yes	machine-local, short-lived; discarding one is already supported, so a lost key costs a proposal that can be made again
exports	no	an export exists in order to move; its destination is where that data's at-rest control belongs
skill files	no	they are meant to be opened in an editor; an encrypted file a person cannot read is a broken skill, not a safer one

The first attempt was wrong, and the tests said so immediately

"Seal, and raise if you cannot" is what secure-by-default sounds like it should mean. It broke ten tests on a machine with no passphrase, no systemd credential and no TPM tooling — which is every developer machine and most first runs. Staging a skill proposal failed outright.

CISA's own wording is that a product should be resilient out of the box without end-users having to take additional steps, and requiring key custody to be configured before a core feature works is exactly such a step. A default that turns an unconfigured install into a broken one is an outage with a rationale.

Sealing now degrades: where no key source exists the blob is written in the clear and the fact is logged once per class rather than hidden, because an operator who believed sealing was on should learn it from a log and not from an incident. sealed?/1 reports what any blob actually is, so nothing is inferred from configuration.

Evidence

mix gate exit 0; 612 passed, 18 excluded; coverage 80.31%. The reasoning is recorded in docs/encryption-at-rest.md under "Which layer carries the compliance control, and which does not", so the next person to ask this question finds the answer and its sources rather than re-deriving them.