Lattice Lab · [3] · Security Architecture

Cryptographic System Design vs Protocol Design: A Missing Layer in Security Architecture

Yannik Goldgräbe · 18 Mar 2026 · 6 min read

AbstractMost teams treat cryptography as a protocol-level concern. In practice, the failures cluster one layer up — in how secure protocols are composed into a system.

When something goes wrong with cryptography in production, the instinct is to look at the protocol: the cipher suite, the key exchange, the signature scheme. Yet the protocols themselves are rarely where modern failures originate. The primitives are well analyzed and the libraries are mature. Failures cluster in the layer between a correct protocol and a coherent system — a layer that often has no owner.

This research separates three concerns that are routinely collapsed into one, and argues that the middle one is where security architecture actually lives.

Protocol correctness

Protocol correctness asks whether a primitive or exchange achieves its stated security goal under its stated assumptions. This is the domain of cryptographic analysis and formal proof, and for standardized protocols it is largely a solved, well-trodden problem. Correctness here is necessary. It is also the part teams over-index on, because it is the part with clean answers.

System-level security composition

Composition is what happens when correct protocols meet each other and the rest of the system. A signature is verified, but nothing binds it to the request it was meant to authorize. Two protocols are each sound, but share a key or a nonce space in a way neither analysis anticipated. An identity is authenticated at the edge and then trusted unconditionally everywhere behind it. None of these is a broken protocol. All of them are broken systems.

This is the missing layer. Security composition is an architectural property: it depends on how trust flows between components, what each one assumes about the others, and whether those assumptions are ever actually checked. It cannot be delegated to a library, because it lives in the spaces between libraries.

Operational cryptographic risk

The third concern is what happens over time. Keys are rotated, or they are not. Certificates expire on a Friday. A migration leaves two schemes live at once. An algorithm that was sound at design time needs replacing while the system keeps running. Operational risk is where cryptography meets the lifecycle, and it is consistently underestimated because it does not appear in the threat model — it appears in the runbook.