NIST 800-53 encryption requirements and FIPS 140 modules

What NIST 800-53 requires for encryption and FIPS 140 validated modules

If a contract or FedRAMP authorization now asks for encryption evidence, start with the decisions that SP 800-53 leaves to your organization. The control SC-13 (Cryptographic Protection) requires you to determine your organization's cryptographic uses and implement the type of cryptography each use requires. SC-8 (Transmission Confidentiality and Integrity) requires you to protect the confidentiality and or integrity of transmitted information, and SC-28 (Protection of Information at Rest) requires the same for defined information at rest. The control catalog names the outcomes, but your organization owns the choice of algorithms, key lengths, data stores and the boundaries where protection applies.

How much work this takes, and whether validated cryptographic modules are mandatory, depends on three things: the system's impact level, the FedRAMP class if you are authorized under FedRAMP, and how keys are managed today. FedRAMP's Cryptographic Module Use rules require providers to document the modules protecting federal customer data and whether those modules are validated under the NIST Cryptographic Module Validation Program. Class D providers must use modules with active CMVP validations, Class C should, and Classes A and B may. FedRAMP rule CMU-CSO-CAT adds that tenants should default to validated cryptographic services when such modules are available. Confirm the class and the rule set that apply to your authorization before scoping any remediation.

Two Release 5.2.0 facts affect planning. Release 5.2.0 withdrew all four SC-13 control enhancements, so SC-13 now relies on its two organization-defined parameters and your own documented decisions. SC-28(1) is selected in both the moderate and high baselines of SP 800-53B, so systems at those levels need at-rest encryption evidence that goes beyond a policy statement. FedRAMP also requires SC-8 and SC-8(1) at Classes B, C and D, with SC-8 assessed in an independent assessment every year. Ask your assessor which cryptographic modules and key stores they will sample, and collect the module validation certificates before the assessment begins.

How encryption obligations differ by baseline and FedRAMP class

A system categorized at the moderate impact level under SP 800-53B selects SC-8 and SC-28 at the base level, and the moderate baseline also selects SC-28(1), which addresses cryptographic protection of information at rest. The baseline tells you which controls to implement, but it does not by itself say which cryptographic modules you must use. That detail comes from the authorizing official, the agreement that governs the data, or the sector rule that applies.

SC-8 in transit: Transmitted information needs protection of confidentiality or integrity, and your design should show which paths use encryption and which do not.
SC-28 at rest: Defined information at rest needs protection, so the system security plan should name the data stores and the mechanisms that cover them.
SC-28(1) cryptographic protection: The moderate baseline adds this enhancement, so storage encryption must be documented, not assumed from a default setting.
Module validation: SC-13 requires you to determine each cryptographic use, but whether the modules must be CMVP-validated depends on the agreement or authorizing body.
Evidence: Keep configuration exports, certificate inventories and key-management records that match the cryptographic uses you listed.

Ask the authorizing official whether a validated module is expected for each use case and whether any sector rule adds requirements above the baseline.

Why CMVP-validated modules matter for SC-13 and SC-28

SC-13 and SC-28 describe outcomes: the organization decides which cryptography protects each use, and information at rest is protected in a defined way. Neither control asks for a specific product or certificate. That gap is where the Cryptographic Module Validation Program (CMVP) comes in. The CMVP is run by NIST with Canada's Communications Security Establishment, and it tests a cryptographic module, meaning the specific software, firmware or hardware that performs the cryptographic operations, against the FIPS 140 security requirements. A control can be satisfied by strong algorithms alone, but an assessor or contract may separately ask whether the module doing the encryption was itself tested and listed. Those are two different questions, and a yes to one does not answer the other.

Algorithms and modules are easy to confuse. An approved algorithm, such as AES or a NIST-approved hash, is a mathematical method. A validated module is an implementation of that method, plus its key handling, self-tests and operator interface, that has been evaluated by an accredited laboratory and listed on a CMVP certificate. A product can say it uses AES-256 and still have no validated module behind that claim. Ask the vendor or your platform team which module performs TLS termination, disk or database encryption, and key generation, and get the certificate number for each. Then confirm the certificate's status, including whether it is active, historical or revoked, directly in the CMVP validated modules database rather than relying on a datasheet or a sales statement.

Plan for this before the assessment window. Inventory every component that encrypts data in transit or at rest, record the module name, version and certificate number, and note whether the platform is configured to use those modules in FIPS mode. Open-source components often rely on a separately validated library, so the module boundary may sit under the application rather than in it. Where a platform or a dependency has no active validation, record that as a finding with a remediation path, because FedRAMP rules and some federal contracts treat validated cryptography as a separate expectation from the control itself.

What FedRAMP's 2026 cryptographic module rules require by class

FedRAMP's Cryptographic Module Use rules set what a cloud provider must document about the modules protecting federal customer data, and how strictly validation is expected by certification class. Each card below is one rule or check that changes the evidence package a provider assembles for its SC-13, SC-8 and SC-28 controls.

Document every cryptographic module

Providers must document the cryptographic modules that protect federal customer data, including where each module runs and which services depend on it. For SC-13 and SC-28, this inventory is the starting evidence: an assessor will ask which module performs each encryption use and whether that module is validated under the NIST Cryptographic Module Validation Program. Build the inventory from configuration and key management records, not from memory, and confirm it against the boundary in the system security plan.

Active CMVP validation for Class D

Class D providers must use cryptographic modules with active CMVP validations. Active means the validation certificate is current, not sunset or revoked, so the check has to be repeated as certificates change status. Confirm each module's validation certificate number and status against the CMVP listings before the assessment, and record the date of that check. A module that is validated but no longer active does not satisfy this rule.

Validation expected for Class C

For Class C, the rules say providers should use validated modules. This is a weaker obligation than the Class D requirement, but it still shapes the evidence. A provider that relies on unvalidated modules at Class C should expect to explain the decision in its documentation and to show why no validated alternative fits the service. Ask the assessor how they will treat an exception before the assessment begins.

Validation optional for Classes A and B

Classes A and B may use modules that are not validated. Providers that choose this path still need to document their cryptographic modules, so the flexibility applies to the validation status, not to the inventory. Teams should decide early whether a single validated module set will be used across all classes, because a split between validated and unvalidated modules multiplies the evidence each assessment must cover.

Default to validated services for tenants

Rule CMU-CSO-CAT says providers should configure agency tenants by default to use cryptographic services built on modules with active CMVP validations when such modules are available. The evidence is the default configuration itself: the key management and TLS settings a new tenant receives, plus any documented override. Check that TLS libraries, key stores and disk encryption services resolve to validated modules out of the box, and record every setting an agency can change away from that default.

How to prepare encryption evidence before an assessment

This sequence moves from knowing where data is to proving that each cryptographic use is chosen, validated where required, configured, documented and traceable to a control. The assessor receives a package that can be tested against SC-13, SC-8 and SC-28 without reconstruction.

Build the cryptographic inventory
Map every data flow and data store in the system boundary, including user sessions, service-to-service calls, backups, logs, replicas and exports. Record for each one the data type, the protocol or storage layer, the system component that performs encryption and the owner. The output is a cryptographic inventory that lists each use of cryptography, and you know it is done when the platform team and the system owner can each trace every boundary crossing to a row in the table.
Decide cryptography for each use
SC-13 asks the organization to determine its cryptographic uses and implement the type of cryptography each use requires. For every inventory row, the security lead records the algorithm family, key length or mode, the reason it fits the data sensitivity, and any organization-defined parameters the system security plan requires you to set. The output is a cryptographic decision register approved by the authorizing official or delegate, and it is complete when no inventory row lacks an approved entry.
Confirm module validation status
For each decision, identify the module that performs the cryptography, such as a library, operating system component, hardware security module or load balancer. Check the module's validation status in the NIST Cryptographic Module Validation Program and record the certificate number, the validated version and whether the validation is active. Where a module is not validated, record the gap and the compensating plan. The output is a module register, and it is complete when every module in the register has a verified status and a named owner.
Configure transit encryption
Apply SC-8 by enabling encryption for every boundary crossing in the inventory, including internal hops that cross trust zones. Configure protocol versions, cipher suites and certificate chains to match the decision register, and disable fallbacks the register does not allow. Confirm with the module register that the configured stacks use validated modules where the applicable authorization requires them. The output is a set of versioned configuration files, and the step closes when a scan of each endpoint shows only approved settings.
Configure at-rest encryption
Apply SC-28 to every store in the inventory, covering databases, object storage, volumes, backups, snapshots, logs and caches. Set the encryption method, the boundary at which encryption applies and the key scope for each store, and confirm that temporary files and exports inherit the same protection. Where the baseline selects enhancements, implement them and record how each is met. The output is a store-by-store configuration record, and the step closes when a sample of each store type confirms encryption is active.
Document key management
Write the key lifecycle for each key class: generation, storage, access, rotation, backup, revocation, destruction and recovery. Name the key custodians, record where keys are held (software keystore, hardware module or external service) and state how key access is logged and reviewed. Confirm that the key hierarchy in the platform matches the decision register. The output is a key management procedure with a key inventory, and it is complete when each key in the inventory maps to a lifecycle entry and an owner.
Collect configuration evidence
Gather dated, reproducible evidence: configuration exports, infrastructure-as-code files, scanner output for TLS endpoints, screenshots or API responses showing encryption settings, module certificate records and key inventory extracts. Store each item with its source, collection date and the control it supports. Where tooling is self-hosted, record the tool version and the query used. The output is an evidence index keyed to the cryptographic inventory, and the step closes when each control in scope has at least one item that an assessor can re-check.
Hand the package to the assessor
Assemble the inventory, decision register, module register, configuration records, key procedure and evidence index into one package, and walk the assessor through how each item traces to SC-13, SC-8 and SC-28. The independent assessor performs the testing and issues the findings, and the organization owns the remediation of any gaps. Confirm the review schedule, the access arrangements and the expected deliverables in a written scope before the package is shared. The step closes when the assessor confirms receipt and lists any open questions.

What must be in place before an assessor tests encryption

An assessor testing SC-13, SC-8 and SC-28 will ask for proof that the cryptography is known, validated, configured and documented before any test begins. The checks below connect the inventory of cryptographic uses to the system security plan and to configuration evidence that can be produced on request.

Current inventory of cryptographic uses

SC-13 starts with determining the organization's cryptographic uses and implementing the type of cryptography each use requires. Build a register that lists every place the system encrypts or signs data: TLS listeners, database encryption, backup encryption, disk encryption, message signing, password hashing and API tokens. For each entry, record the algorithm, key length, owning team and the component that performs the operation. An assessor will compare this register against scans of live endpoints, so gaps here show up quickly.

Documented module validation status

For each cryptographic use, record whether the module that performs it is validated under the NIST Cryptographic Module Validation Program and which validation certificate applies. Be precise: a product that uses an algorithm is not the same as a validated module, and the certificate must cover the version and mode in production. Confirm the status against the CMVP listing rather than vendor marketing, and note any module running outside its validated configuration so the gap is documented before the assessor finds it.

TLS and at-rest configuration baselines

SC-8 and SC-28 are tested against written settings, so keep a baseline for each service that protects data in transit or at rest. For TLS, document accepted protocol versions, cipher suites, certificate sources and HSTS settings for every listener, including internal service-to-service traffic. For storage, document volume and database encryption settings, key locations and which data classes are covered. Store the baselines in version control so each change has an author and a date.

Key lifecycle records

Encryption controls fail on key management, not on the algorithm. Keep records that show how keys are generated, where they are stored, who can use them, when they rotate and how they are destroyed or revoked. Include certificate expiry dates, the process for emergency rotation and the chain of custody for keys held in a hardware security module or a self-hosted key manager. Ask the team to demonstrate one full rotation cycle in a test environment so the records describe what actually happens.

System security plan entry for each SC control

The system security and privacy plan must state how each applicable SC control is implemented in this system, who is responsible and where the evidence lives. For encryption, that means one entry each for SC-13, SC-8 and SC-28 that names the cryptographic modules, the baselines and the owner. Check which enhancements your baseline selects, for example SC-28(1) in the moderate and high baselines, and state whether each is implemented, inherited or planned. Confirm the entries match the inventory and the baselines above.

Repeatable evidence on demand

An assessor may ask for proof of current configuration at any point in the assessment, so the team needs a way to produce it without rebuilding it by hand. Use scripted checks or compliance-as-code content that query TLS endpoints, storage encryption and key stores, then save the output with a timestamp and the system version. Keep the scripts, their output and a short runbook in the evidence repository. Confirm with your assessor which output format they accept before you build the process.

Questions buyers ask about encryption under NIST 800-53

Does NIST SP 800-53 itself require FIPS 140 validated encryption?

SP 800-53 does not name a specific validation program in the control text that you can rely on as a blanket rule, so read SC-13 as requiring you to determine each cryptographic use and implement the type of cryptography that use requires. SC-13 has 2 organization-defined parameters and 4 control enhancements, all withdrawn in Release 5.2.0. Whether a validated module is mandatory depends on your system's authorization, your agency or contract, and the rules that govern it. Confirm the requirement with the authorizing official or contracting officer before choosing modules, and document the reasoning in your system security plan so the assessor can trace it.

What does FedRAMP require for cryptographic modules by class?

FedRAMP's Cryptographic Module Use rules require providers to document the cryptographic modules that protect federal customer data and state whether each is validated under the NIST Cryptographic Module Validation Program (CMVP). Class D providers must use modules with active CMVP validations, Class C providers should, and Classes A and B may use them. Rule CMU-CSO-CAT adds that providers should configure agency tenants to use cryptographic services built on active CMVP-validated modules when such modules are available. Check the current FedRAMP rules for your class before you scope the work, because the requirements are versioned.

Who owns the cryptographic decisions for a system?

Your organization owns them. Deciding which data needs protection, which algorithms and key lengths apply, which modules are acceptable, and how keys are managed is a risk decision tied to your system's authorization and your accountable officials. An implementation partner can propose a design, configure the chosen modules and prepare the evidence, but the decision and its sign-off stay with your team. Only an independent assessor issues the assessment conclusion, and no partner, including DeployOpen, issues reports or certifications.

Can an implementation partner configure encryption and prepare the evidence?

Yes, within a written scope. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, which covers configuring TLS for data in transit, encryption at rest for storage and databases, and key handling where the platform supports it. The engagement can also prepare configuration exports, diagrams and test records that an assessor will examine. Confirm in the scope which platform components use validated modules, because the platform's own cryptographic libraries and their validation status must be verified against the CMVP listing, not assumed.

What does the work need from our internal staff?

Plan for named owners on your side for key decisions, access to the systems and their cloud or data center accounts, and time from the people who run the platforms day to day. Your security lead will need to approve the cryptographic inventory and the module choices, your architects will confirm data flows and boundaries, and your operations team will take over the configurations after handover. Ask the partner to list these dependencies in the written scope with the roles that provide each one, since delays usually come from slow sign-off rather than from configuration work.

Can we get a cost estimate without a written scope?

Not a reliable one. NIST does not estimate certification or compliance costs and does not set implementation timelines, so no published NIST figure answers this question for your system. Cost depends on how many systems and data flows are in scope, how many cryptographic uses you have, which platforms need configuration, whether validated modules must be verified or replaced, how much evidence the assessor expects, and who pays the independent assessor. DeployOpen does not publish a price list; a quote follows from a written scope that lists the systems, deliverables and timeline you agree on.

What will the assessor test for encryption?

The assessor will compare your documented cryptographic uses against the implemented configuration. Under SP 800-53A, the assessment procedure for each control combines determination statements with examine, interview and test methods, so expect them to review your policy and system security plan, interview administrators, and test live settings. For SC-8 and SC-28, they will check that transmitted and stored data is protected as your plan says, and for FedRAMP-scoped systems they will check module documentation and CMVP status. Prepare a current inventory of cryptographic uses, module versions, certificate references and configuration evidence, and confirm the final determinations with your independent assessor.

How an implementation partner prepares encryption evidence

DeployOpen plans, configures and documents self-hosted open-source platforms inside the client's own infrastructure, and prepares the cryptographic configuration and evidence for those systems. In practice that means mapping each cryptographic use to SC-13, recording which TLS settings protect SC-8 transmissions and which storage encryption settings support SC-28, and writing down which cryptographic modules each component uses. The work product is handed to the organization, which owns its controls, and to its assessor, who decides whether the evidence supports the control. Reviewing the module documentation with the client's security and compliance leads before handover is where most gaps surface, such as a service that quietly negotiates a cipher outside the approved list.

The organization should expect its partner to deliver specific artifacts: a cryptographic inventory, configuration files and their change history, key and certificate management procedures, and a record of which validated modules are in use and how they were confirmed against the NIST Cryptographic Module Validation Program. Ask for each item to be tied to a named system component and a named control. Confirm with the partner which parts are one-time (design, hardening and documentation) and which recur (certificate renewal, key rotation, re-testing after upgrades), because those recurring tasks determine who will maintain the evidence after the project closes.

DeployOpen does not issue assessment reports, attestations or certifications. Only an independent assessor, auditor or certification body can do that, and hiring DeployOpen does not guarantee an assessment outcome. The assessor will test the configuration directly and may find weaknesses that the partner's own documentation did not show. Organizations should therefore agree in the written scope who fixes findings, how retesting is handled, and what the partner will and will not do during the assessor's testing window.

How DeployOpen scopes encryption readiness work

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, then prepares the encryption configuration, key handling and evidence that an independent assessor will examine for SC-8, SC-13 and SC-28. We do not issue assessment reports or validation certificates; the organization owns its controls and an independent assessor reaches the conclusions.

How we scope

We list every transmission path and data store that holds in-scope information before any work starts.
The written scope names the cryptographic uses, modules and platforms covered, and the ones excluded.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work begins.

How we build

We configure TLS and at-rest encryption on the self-hosted platforms within your cloud accounts or data centers.
We record which cryptographic modules are in use and check their validation status against the CMVP listing.
We test encryption settings and fix gaps, then document each configuration against the control it supports.

How we hand over

You receive configuration records, key management procedures, module inventories and test results in your own repositories.
Each control has a written mapping from the requirement to the configuration and the evidence that shows it.
Your team walks through the handover so staff can operate and reproduce the encryption setup without us.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
Retainers can cover module updates and key rotation checks when platform versions or FedRAMP class requirements change.
Confirm with your assessor which evidence they will accept before the assessment window opens.

NIST 800-53 encryption and FIPS 140 validated modules