The Change Surface: API, Kernel, Hardware, Cloud, Legacy

The end-to-end path is now visible, but the path can change only through the components that implement it. The subject here is the implementation stack behind post-quantum migration: application interfaces, cryptographic providers, kernels, embedded systems, hardware, cloud services, and legacy boundaries. Classifying each dependency by its update boundary shows who owns the change, what crosses the interface, and why a library upgrade may be necessary without being sufficient.

An API boundary helps only when the operation can cross it

A cryptographic application programming interface (API) separates the application's high-level work from the provider or library that performs encryption, signatures, hashing, key establishment, or random-number generation. The application can ask for a cryptographic operation without containing every algorithm's implementation. If the API presents compatible operations and the provider can be replaced securely, a new algorithm may be introduced without rewriting the application's core logic.

That separation is a real form of crypto agility, but it has a specific condition: the interface must represent the differences that matter. Post-quantum keys, signatures, and ciphertexts can be larger. An API that assumes a fixed buffer, fixed key length, or fixed parameter shape may turn an apparently abstract operation back into an algorithm-specific dependency. The interface must also be understandable enough for developers and administrators to use the intended operation, and the provider update path must be protected, tested, and documented. Abstraction reduces coupling; it does not make coupling disappear.

Policy often belongs at this boundary. NIST describes a system administrator, sometimes acting on a policy set by a chief information security officer, deciding whether an algorithm is allowed. A provider can make an encryption call fail when policy disallows a legacy algorithm while still allowing decryption of existing files or messages that require it. That distinction is important for migration. “Do not create new protection with the old mechanism” and “make all old data unreadable immediately” are different operational policies. The API and provider need enough context to enforce the first without accidentally destroying the second.

The owner of the API boundary is therefore not only the application team. Developers own how the application requests cryptographic services. Library maintainers own provider behavior and update safety. Security administrators own the permitted choices and the conditions under which a legacy operation remains available. If any of these owners treats the interface as a permanent contract with today's algorithms, the next transition becomes a code change or an emergency exception instead of a controlled policy change.

The boundary becomes narrower when cryptography runs in privileged system code. Some security protocols operate in an operating-system kernel; disk encryption is another example. In those cases, the cryptographic API must be available inside the kernel, but many systems expose only the subset required by kernel operations. Supported algorithms may be fixed when the kernel is built, and plugins that can add a provider after deployment may not be available. A user-space application can receive a library update while the kernel path that protects network packets or storage remains unchanged.