Rule 10 of 12 · Chapter III — Running Keys in the Open
Issue a distinct key for each party, device, and purpose so that one disclosure does not become total.
Why this rule exists
A shared key converts any single compromise into a full compromise: one stolen laptop, one cloned device, one departing contractor, and every message everywhere is readable. Separate keys turn a catastrophe into a contained incident you can scope, revoke, and explain. Separation by purpose also prevents cross-protocol attacks, where a signature oracle in one context forges material usable in another.
In practice
Derive per-device and per-session keys from a root using a KDF with context binding rather than distributing the root itself. Use different keys for encryption and authentication, for production and staging, for each tenant, and for each protocol direction. When you log a key's existence, record who holds it and what it is for, so revocation has a precise blast radius.
When it doesn't apply
A shared group key is legitimate when the group genuinely is the unit of trust — broadcast to a fleet, or a multicast stream where per-recipient encryption is infeasible. Key separation also costs provisioning and storage; on very constrained devices you may collapse purposes, provided you still keep the key unique per device.