CLOUD INFRASTRUCTURE
The certificate is narrower than you think
Every conversation about federal cryptography starts in the same place: someone asks whether the platform is FIPS validated. It is a reasonable question with an unreasonable answer, because validation does not apply to platforms. It applies to modules, and a module is whatever the vendor drew a line around when they submitted for testing.
That line matters enormously. A validated module might cover only the kernel cryptographic library on a single operating system version, at a single patch level, in a single operating mode. Move outside any of those and the certificate no longer describes what you are running. Assessors know this, which is why the first request in a serious review is not the certificate number but the security policy document that accompanies it.
Where the boundary sits at ServLogi
We treat the cryptographic boundary as a property of the deployment rather than the product. For every enclave we run, the boundary encloses four things: the hardware security module that holds root key material, the key management service that mediates access to it, the in-memory encryption engine on the host, and the transport layer terminating at the enclave edge.
Anything outside that set is explicitly out of boundary and documented as such. This is less flattering than a marketing claim of end-to-end validation, and considerably more useful when an assessor arrives with the control catalogue open.
Algorithms are the easy part
Approved algorithm selection is close to a solved problem. AES-256 in an approved mode for data at rest, an approved key establishment scheme for transport, and an approved hash for integrity will satisfy nearly every federal requirement in force today. The published algorithm lists remove most of the judgment from the decision, which is exactly what they are for.
The difficulty is downstream. An approved algorithm implemented against a key that was generated on a workstation, emailed to an engineer, and pasted into a configuration file is not a compliant system. It is a compliant algorithm wrapped around a custody failure.
Custody is the control that fails
In our experience reviewing environments that arrive mid-authorization, key custody accounts for the large majority of cryptographic findings. The patterns repeat:
- Keys generated outside a validated module and imported afterwards, which voids the assurance the module was selected to provide.
- Escrow copies held for operational recovery in a store with weaker access control than the primary.
- Service accounts with standing decrypt permission, so a single credential compromise reads the entire data set.
- Rotation defined in policy, implemented once during onboarding, and never executed again.
None of these are exotic. All of them are findings. The reason they persist is that each one is individually reasonable at the moment it is introduced, usually under delivery pressure, and none of them produce a visible failure until an assessment or an incident forces the question.
Rotation is a continuous control
Rotation is where paper compliance and operational compliance separate most cleanly. A policy stating that data encryption keys rotate every ninety days is trivial to write and genuinely difficult to run against a live fleet without customer-visible disruption.
The mechanism that makes it survivable is envelope encryption with versioned key material. Data encryption keys are wrapped by a key encryption key held in the hardware module. Rotation replaces the wrapping key and re-wraps, which is a small, fast operation, rather than rewriting the data itself. Old versions stay available for decryption until the last object under them has been re-wrapped, and the fleet reports how many objects remain under each version.
That last part is what turns rotation into evidence. The control is not the policy document. The control is the counter that goes to zero, on a schedule, visible in the same telemetry pipeline that carries everything else.
What to ask a provider
If you are evaluating any accredited cloud, including this one, four questions separate a real cryptography program from a certificate on a web page:
- Where exactly is the cryptographic boundary drawn, and can I read the security policy that defines it?
- Who can cause a decryption to happen, and what is the evidence trail when they do?
- How is rotation executed and measured, and can I see the current state rather than the policy?
- What happens to key material at contract termination, and how is destruction evidenced?
A provider that answers all four without escalating is running the program. One that cannot is selling the certificate.