Cryptography begins with the threat model

Cryptography becomes useful when it is tied to a communication problem: who can read, who can alter, who can impersonate, what can be replayed, and what failure actually costs.

The threat model names assets, principals, trust boundaries, physical access, network position, update authority, and recovery cost. A nearby passive listener is different from a compromised gateway; stolen flash is different from a malicious firmware signer. The primitive follows those capabilities. Without that ordering, “encrypted” can hide unauthenticated messages, replayable commands, weak key storage, or a recovery path that bypasses the entire design.

Start with the insecure channel and add only the guarantees the system needs. On constrained devices, discipline matters more because there is no convenient TLS-shaped escape hatch.

Authenticated encryption protects confidentiality and integrity only when nonces never repeat under a key and the associated data binds the right protocol context. Sequence numbers and replay windows need durable reset semantics. Key rotation needs overlap and revocation rules. Device identity needs a provisioning root and an incident path. Every guarantee creates state, and every piece of state needs power-loss, rollback, and manufacturing behavior.

The standard is not cleverness. Use established primitives, keep nonces honest, rotate keys deliberately, expose the threat model, and let an audit attack the assumptions before production does.

The implementation proof includes known-answer vectors, malformed-input tests, downgrade resistance, constant-time review where secrets influence control flow, fuzzing at parser boundaries, and explicit zeroization limits. It also includes operational questions: who can rotate a key, what telemetry reveals authentication failures without leaking secrets, and how a fleet recovers after compromise. Security is the complete lifecycle, not the successful decrypt call.