SC-13 Cryptographic protection: requirements and evidence

What SC-13 cryptographic protection asks for and why assessors check it

If an assessor, a contract or a FedRAMP authorization requires SC-13, the organization must do two things: determine each of its cryptographic uses, and implement the type of cryptography that each use requires. The control does not name one algorithm or product for every case. It makes the organization decide where cryptography protects the system, what kind of protection each purpose needs, and then prove that the decision is carried out. Assessors check that chain from the decision through to the configuration, so a team that cannot list its cryptographic uses will struggle to show that any of them are correct.

Unmanaged cryptography is a common source of exposure. A service may rely on an old protocol version, a weak cipher suite, a self-written routine or a module that was never validated, and nobody in the organization may know it is there. Keys can be stored beside the data they protect, or certificates can expire without anyone tracking them. The base control carries the whole requirement, because all four of its enhancements are withdrawn in SP 800-53 Release 5.2.0. Teams that read older guidance should not look for enhancement-level expectations. Assessors will test the base control and the cryptographic decisions it implies, and the Release 5.2.0 assessment procedure for SC-13 uses two determination statements.

The hard part is usually the inventory, not the cipher choice. Cryptography sits in web servers, databases, backups, message queues, identity providers, VPN gateways, container platforms and third-party SaaS products, and many of these are configured by different teams or vendors. Start with a register of cryptographic uses that names the data or channel, the system, the algorithm and module, and the owner. Then ask each product owner for evidence of its module validation status, which is what the examine objects for SC-13 point to, such as cryptographic module validation certificates and the list of FIPS-validated modules. Confirm current validation details directly with NIST's Cryptographic Module Validation Program and with each vendor, because validation status changes over time.

Which systems, data and uses fall under SC-13 scope

SC-13 reaches every place a system uses cryptography, so scope starts with an inventory of uses and then covers the systems and services that perform them. Related controls such as AC-2, AU-9, IA-5 and CP-9 draw on the same inventory and evidence, so a complete record here supports several assessments at once.

Data in transit

Every channel that carries controlled data needs a documented cryptographic choice, including user sessions, service-to-service calls, replication, administrative access, VPN tunnels and email relays. Start with a data flow diagram that lists each hop, then record the protocol, cipher suite and whether the implementing module is FIPS-validated. Assessors compare this list against the configuration settings they examine, so gaps in the diagram become gaps in the assessment.

Data at rest

Databases, file stores, object storage, volumes and backups all hold data that SC-13 may reach. Confirm which layer performs encryption (application, database, volume or storage service) and who holds the keys. Nextcloud server-side encryption, for example, protects file contents but does not encrypt file names or folder structure, so that metadata gap belongs in the scope record with a documented risk decision.

Authentication, signing and integrity

Cryptography also protects passwords and tokens, signs software artifacts and container images, and protects audit logs and message integrity. Each of these uses is a separate decision about algorithm and module type. Record signing and hashing explicitly, because an inventory that covers only encryption leaves them outside the assessment. Authenticator controls under IA-5 and audit log integrity under AU-9 rely on the same evidence.

Key generation and storage

Keys protect every other use, so the scope must name where keys are generated, stored, rotated and destroyed. A transit encryption service such as OpenBao can encrypt and decrypt application data, sign and verify data, and keep versioned keys with rotation, so applications send data to the service instead of handling key material directly. SC-12 governs the key lifecycle, so the SC-13 record should reference it and list each key type it protects.

Cloud and managed services

Managed databases, object storage, key management services, SaaS platforms and load balancers each perform cryptography under their own module. Include each one in the boundary, then ask the provider which validated module it uses, for which versions and for which services. Request the module validation certificates and the list of validated modules, since assessors examine both. If a provider cannot supply them, the gap becomes a scoping finding to track.

Baseline selection and FedRAMP

SP 800-53B assigns SC-13 to the low, moderate and high baselines, so it applies whatever the system impact level. FedRAMP's Rev5 baselines require it at Classes B, C and D, and its annual assessment rule requires it in every independent assessment at those classes. NIST SP 800-171 Rev. 3 derives requirement 03.13.11 from SC-13, so one cryptography inventory can serve several frameworks. Confirm the baseline or class with your authorizing body before you finalize scope.

How an assessor tests SC-13 and the evidence requested

This table maps the SP 800-53A assessment elements for SC-13 to the methods an assessor uses, the evidence each one asks for and the findings that most often appear. Read it as a preparation checklist: each row names what the assessor will look for and what your team should have ready before the assessment begins.

Assessment element	What the assessor does	Evidence to have ready	Common finding
Determination statement 1: cryptographic uses	Examines design and configuration records to confirm the organization has determined its cryptographic uses (for example data in transit, data at rest, authentication, signing).	System design documentation listing each cryptographic use, the data it protects and the system component that performs it.	Cryptographic uses exist in the system but were never listed, such as internal service calls, backup jobs or signing in custom code.
Determination statement 2: required cryptography type	Checks that each identified use is implemented with the cryptographic type the organization selected, and that the selection is documented.	Documented selection of the required type for each use, with the basis for that choice and the matching configuration settings.	The type is selected on paper but the running configuration uses a different algorithm, protocol version or key length.
Examine: cryptographic module validation certificates	Reviews the validation certificates for each cryptographic module the system relies on and confirms they cover the module version in use.	Current validation certificates for each module, with version numbers that match the deployed packages or libraries.	Certificates are missing, expired, or cover an earlier version than the one deployed after an upgrade.
Examine: list of FIPS-validated cryptographic modules	Compares the organization's list of validated modules against what is actually deployed across the system boundary.	A maintained inventory of modules in use, with validation status and the operating mode in which validated functions are enabled.	Modules are on the list but a non-validated library handles some traffic, or validation applies only in a mode the system does not use.
Examine: configuration settings and associated documentation	Inspects configuration files, service settings and documented exceptions to confirm the approved cryptography is enforced.	Exported configuration baselines, change records for cryptographic settings and documented exception approvals.	Legacy protocol or cipher options remain enabled by default, and no exception record explains them.
Interview: system owners and platform engineers	Asks how cryptographic uses are identified when a new service is added and who approves a change in algorithm or key length.	Procedure for adding cryptographic uses, owner names and records of recent changes.	Teams add services with their own encryption and the central inventory is not updated.
Interview: security and cryptography leads	Confirms who decides the required cryptographic type for each use and how that decision is reviewed.	Named decision owner, review cadence and minutes or tickets showing past decisions.	Decisions are made informally in engineering channels, with no record an assessor can sample.
Test: sample cryptographic uses	Selects several uses from the design documents and verifies the live behavior, for example by checking which module and protocol version handles the connection.	Test output from the system, such as protocol negotiation results, module logs or configuration exports taken from the running environment.	The documented design and the live system disagree, and the difference was not caught by internal review.

How to implement SC-13 step by step

This sequence turns SC-13 from a policy statement into a verified set of cryptographic decisions, each tied to a named system use, an approved module and a configuration an assessor can check.

Inventory every cryptographic use
Start by listing every place the system relies on cryptography: transmission between services, stored data, backups, authentication tokens, signing of software and logs, and key or certificate handling. The system owner leads this with engineering and the security team, reading configuration files, service definitions and data flow diagrams rather than relying on memory. The output is a use register with one row per use, naming the system component, the data or purpose it protects and the owner. You know this step is done when a reviewer can pick any encrypted or signed flow in the environment and find its row.
Decide the required type for each use
For each row in the use register, the organization decides which type of cryptography the use requires. Consult the data classification, the system's security categorization, the applicable contract or regulation, and any agency or customer requirement that names validated modules or approved algorithms. Record the decision and the reason, so the choice can be explained later. The output is a cryptographic requirements record that maps each use to a required type. Confirm the exact standards that apply with the authorizing official, contracting office or your compliance lead, because the SC-13 requirement depends on those external obligations.
Select validated modules and confirm certificate status
For each use that requires validated cryptography, identify the cryptographic module the product actually uses, not just the product name. Obtain the module's validation certificate from the official NIST validation list and check its current status, including any transition or historical notes. Where a product bundles several libraries, confirm which module handles each function. The output is a module decision record listing the module, certificate number, validation status, the uses it covers and the date you checked. Record the check date, because certificate status can change and an assessor will ask when you last verified it.
Configure systems to use only approved modules
Set each component to use only the modules recorded in the decision record. This usually means enabling a validated mode or FIPS mode where the product offers one, disabling weaker algorithms and protocol versions, and blocking fallback paths that would use unvalidated libraries. Keep the configuration in version-controlled infrastructure code so changes are reviewed. Confirm with the product vendor which settings enable validated operation, since not every setting does. The output is a hardened configuration baseline for each component, and you know this step is done when a test connection negotiates only the approved algorithms.
Document the decisions in the system security plan
Write the cryptographic decisions into the system security plan so the SC-13 implementation statement explains what is used, where and why. Link each statement to the use register, the module decision record and the configuration baseline. Name the role responsible for keeping each entry current and state how changes to modules or uses trigger an update. The output is a completed SC-13 implementation section in the plan, and you know this step is done when every use in the register has a matching statement and an owner.
Verify configuration and collect evidence
Test the running system against the baseline. Check configuration settings on each component, review the system design documentation against the use register, and confirm that the modules in use match the certificates recorded. Automated configuration scanners can help by reporting settings across many hosts, but a reviewer should still spot-check results. Schedule repeat checks whenever modules, libraries or configurations change. The output is a verification report with dated configuration evidence for each use. You know this step is done when the evidence set lets an independent assessor trace each use from the register to a validated module and a live setting without relying on interview answers alone.

Choosing FIPS-validated or other approved cryptography for each use

SC-13 forces a decision for every cryptographic use in the system: which type of cryptography applies, and whether that type must come from a validated cryptographic module. Start by listing each use (TLS for user and service traffic, database and backup encryption, key wrapping, digital signatures, password or token hashing) and asking which ones a contract, agency or regulator has tied to FIPS-validated modules. A validation certificate is not the same as using a strong algorithm. An algorithm can be sound and still be unusable for a regulated use if the implementation that runs it has not been tested and validated under the FIPS 140 program. The assessor's examine objects reflect this: cryptographic module validation certificates, a list of FIPS-validated modules, system design documentation and configuration settings that show which module actually performs each operation.

FedRAMP's Rev5 baselines require SC-13 at Classes B, C and D, and its annual assessment rule requires SC-13 in a FedRAMP independent assessment every year at those classes. FedRAMP points providers to its Cryptographic Module Use rules, so cloud providers pursuing FedRAMP should read those rules alongside the control. For nonfederal systems handling controlled unclassified information, NIST SP 800-171 Rev. 3 derives requirement 03.13.11 (Cryptographic Protection) from SC-13, so the same module question arises in a contractor scope even without a FedRAMP authorization. Where a national security use is involved, check whether an NSA-approved type is required instead, since the control allows that choice per use.

Confirm module status with the validation list maintained by NIST and the certificate for the exact module version and operating environment you deploy. Do not assume that a library or distribution is validated because its vendor describes it as FIPS-capable or FIPS-compliant. Ask the implementation partner and your auditor to record the certificate number, the module boundary and the mode in which the module runs for each use, and to flag any use that falls back to a non-validated library. Re-check the list when you upgrade, because a certificate can change status and the approved mode of a module can differ from its default configuration.

Evidence that satisfies SC-13 and how to keep it current

An assessor testing SC-13 checks whether you know where cryptography is used, which type applies to each use, and whether the implementation matches that decision. The cards below cover the records that prove those points and the refresh triggers that keep them accurate between assessments.

Cryptographic use register

This is the central list of every place the system uses cryptography, with the purpose, the data or traffic protected, the algorithm, the module that performs it and the required type for that use. SC-13 begins with this determination, so it is the first artifact an assessor asks for. Check that each row names an owner and that every service in the system design appears in it. Review the register when a new service, data store or integration is added, and when a regulator or contract changes the required cryptography.

FIPS module certificates and validation list entries

For each use that requires FIPS-validated cryptography, keep the module's validation certificate and confirm that the exact module name, version and operating environment appear on the published validation list. The examine objects for SC-13 include both the certificates and the list, so a certificate alone is weak evidence. Confirm that the deployed build matches the validated version, because a patched or rebuilt library can fall outside the validated configuration. Record the check date each time you refresh the entry.

System design documentation

Design documents show how cryptography is placed in the architecture: which components terminate TLS, where data is encrypted at rest, how keys are separated from data, and where cryptographic modules sit in the request path. An assessor uses these documents to test whether the determinations in the register match the system as built. Update the diagrams and descriptions when you change a network path, add a proxy or move a database. Stale diagrams are one of the most common reasons evidence fails review.

Configuration exports

Configuration exports prove the running system enforces the decisions in the register. Examples include TLS protocol and cipher settings on load balancers, server-side encryption settings for file and database storage, and the FIPS mode flag on operating systems and runtimes. Export these settings from the live system on a schedule and keep the output with its date and host identifier. Scripted policy checks, such as those from a configuration assessment tool, can produce repeatable exports, but you should confirm each check against the register.

Key management records linked to SC-12

SC-13 says which cryptography to use, while SC-12 governs how keys are generated, stored, rotated and destroyed. Link each cryptographic use in the register to the key records that support it, including key owner, storage location, rotation history and the last destruction event. Assessors often test this link by picking one use and tracing it to its key. Record rotations and retirements as they happen, not at audit time, and recheck the links whenever a key service or encryption backend changes.

Change records for module updates

A change record ties each cryptographic module update, certificate renewal or algorithm change to a review that confirms the module still meets the required type. Without it, the register and certificates may describe a system that no longer exists. Each record should name the change, the affected uses in the register, the validation status checked before and after, and the approver. Pair these records with your configuration management process so that a library upgrade or certificate replacement cannot go live without a documented SC-13 check.

What meeting SC-13 costs in money and effort

This table breaks down the cost and effort components of meeting SC-13 Cryptographic protection, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to build a quote request, because no supplied figures exist for these costs and every amount depends on the scope of your environment.

Cost component	Who is paid or who spends effort	One-time or recurring	What drives it up or down
Cryptographic use inventory and decisions	Internal engineers and security staff, sometimes with an outside consultant for the mapping	One-time, with updates on each significant change	Number of services, data stores and protocols that use cryptography; fewer, well-documented uses lower effort
Configuration and module selection	Platform engineers, or an implementation partner preparing systems	One-time per platform, then recurring with upgrades	Number of distinct cryptographic modules, whether FIPS-validated modules are required, and how many platforms must be reconfigured
Tooling and licenses	Vendor or nothing if self-hosted open source is used	Usually recurring for commercial products	Commercial key management or encryption products add license spend; self-hosted open-source options such as OpenBao can remove that license line but still need hosting and operations
Evidence collection and upkeep	Internal compliance staff or the implementation partner	Recurring, at each assessment cycle	Frequency of key rotation, number of systems to document, and whether evidence is generated automatically
External review or testing	Independent assessor or testing firm, not the implementation partner	Recurring, typically at each assessment	Assessor sampling depth and the FedRAMP class or other framework that sets the annual assessment expectation
Assessor testing effort	Independent assessor fees, billed by their own terms	Recurring, typically annually	Number of cryptographic modules, number of examined objects such as validation certificates and configuration settings, and quality of documentation
Ongoing maintenance and remediation	Internal engineers or a retained support provider	Recurring	Module validation changes, algorithm retirements, and key rotation work after upgrades

Who owns SC-13 and what an outside partner can prepare

Your organization owns SC-13 because the control starts with decisions only you can make: where cryptography is required, which type applies to each use and who accepts the residual risk. These decisions usually stay in-house, even when a partner carries out the technical work.

Use inventory ownership: name an owner for each place data is encrypted, signed, hashed or authenticated, including backups, logs and integrations with external services.
Type selection: decide which cryptographic type each use requires, and record whether FIPS-validated modules are mandated by your contracts, regulators or the baseline you have selected.
Key governance: assign custodians for key generation, rotation and destruction, and approve who may access key material.
Risk acceptance: log every exception, such as a legacy protocol still in use, in the risk register with a named accepting authority and a review date.
Documentation sign-off: approve the SC-13 implementation statement in the system security plan so it matches how the systems actually behave.

Before any partner starts work, check that every SC-13 decision has a named person, a date and a written record.

Where SC-13 implementations usually fall short

SC-13 looks simple on paper: decide where cryptography is required, then choose the right type for each use. The gaps below appear when that decision is never written down, never enforced in configuration, or never kept current. Each card names one gap and the check that exposes it before an assessor does.

No complete inventory of cryptographic uses

Most SC-13 findings start with a missing list. Teams often know their TLS endpoints and disk encryption but miss database column encryption, backup signing, message queue payloads, service-to-service tokens and encrypted exports. Build the inventory from configuration exports, certificate stores, key management records and application code, then tie each use to the data it protects. Ask the question for every system: which cryptographic operation runs here, and who decided it was required?

Validated modules listed but not enabled

A certificate on file does not prove the module is in use. An assessor compares the list of FIPS-validated cryptographic modules against the running configuration. A platform may ship a validated library while the application still loads a general-purpose one, or a FIPS mode flag may be set on one node and missing on another. Check the active cryptographic provider on each service, not only the vendor's datasheet, and record the setting that proves it.

Mixed FIPS and non-FIPS paths

One fallback path can undo the whole design. A service may negotiate a non-approved cipher when a legacy client connects, or a batch job may use a library that bypasses the validated module. These paths are easy to miss because the main flow works correctly. Review cipher suite settings, fallback logic and build dependencies, and document any remaining non-validated use together with its risk acceptance and planned removal date.

Undocumented third-party encryption

Encryption performed by a vendor is still part of your SC-13 scope. SaaS platforms, managed databases, backup services and log shippers often encrypt data with their own keys and algorithms. Request each provider's cryptographic description, module validation status and key custody model in writing, and confirm the contract allows you to evidence them. Where the platform is self-hosted, such as a file sharing server with server-side encryption, the encryption settings and key location belong in your own documentation.

Design documents that describe last year's system

Stale design documentation fails the examine step. SC-13 assessments rely on system design documentation and configuration settings with their associated documentation. When a cipher policy changes, a key rotation schedule moves or a component is replaced, the documents often stay unchanged. Tie the cryptographic inventory to change control, so each approved change updates the design record, and sample a few recent changes to confirm the documents match the running system.

Key management outside the audit trail

Keys that are not governed make every algorithm choice meaningless. Look for keys stored in configuration files, shared administrator accounts that can export material, or rotation performed by hand with no record. A secrets engine with versioned keys and transit encryption can keep key use and rotation visible, but only if its audit output is retained and reviewed. Confirm who can create, rotate and disable each key class, and produce a dated log for one sample key from creation to rotation.

Common questions about SC-13 cost, effort and evidence

How much effort does SC-13 take to implement?

The effort depends on how many cryptographic uses your systems have, not on the control text itself. SC-13 asks the organization to determine each cryptographic use and implement the type of cryptography required for it, so the work starts with an inventory. Teams usually cover TLS for network traffic, encryption at rest, key and certificate handling, signing, and password or token hashing. Each use then needs a documented decision on the required cryptographic type, such as FIPS-validated modules where your requirements call for them, and evidence that the setting is in place. Ask any provider to scope the systems and cryptographic uses in writing before quoting effort.

Can an in-house team implement SC-13 without outside help?

Often yes, if the team has cryptography and configuration skills and clear ownership. The control is organizational as well as technical, so someone must own the cryptographic inventory, the decisions about required cryptographic types, and the review cycle. Most gaps appear in the inventory itself, where teams miss legacy services, backups, internal APIs and third-party integrations. An in-house team should also check that its evidence will hold up: validation certificates for the modules it relies on, current configuration exports, and design documents that match the running system. Outside help is most useful for an independent gap review or for building the evidence set on a tight schedule.

What does an outside partner need from our team to start?

A partner needs access to the systems in scope, the people who run them, and the documents that already describe them. In practice that means architecture and data flow diagrams, a list of systems and services that use encryption, current configuration baselines, identity and key management arrangements, and any existing policy on cryptography. Your team should also name a decision owner who can approve which cryptographic type applies to each use. DeployOpen plans and implements work inside your own cloud accounts, data centers or air-gapped networks, so access is granted through your change control. Scope, deliverables and timelines are agreed in writing before work starts.

How long does SC-13 work take?

No supplied source gives a duration for SC-13 work, so any number you hear should be treated as an estimate from the provider. The length depends on the number of systems, how many cryptographic uses exist, how much legacy configuration must change, and whether validated modules must be adopted or only confirmed. Work that only documents existing, already validated settings is much shorter than work that replaces libraries or re-keys stored data. Ask for a timeline tied to a written scope with named systems, and ask what happens if the inventory turns up uses that were not in scope.

Does NIST publish a price or cost estimate for SC-13?

No. NIST does not offer or endorse any compliance program or tool, and it does not estimate certification or compliance costs. SP 800-53 describes what each control requires, and SP 800-53A describes how assessors test it, but neither sets a price. Costs come from your environment and from who you pay: your staff time, your own tooling, implementation work by a partner, and the fees charged by an independent assessor. Ask every provider for a quote built from a written scope, and keep the assessor's fee separate from implementation fees, since only an independent assessor issues assessment results.

What do assessors ask for first when testing SC-13?

Assessors start with the documents that show what you decided and what the system is configured to do. SP 800-53A lists examine objects for SC-13 that include cryptographic module validation certificates, a list of FIPS-validated cryptographic modules, system design documentation, and system configuration settings with their supporting documentation. Expect the assessor to compare those documents with the running configuration, and to interview the people who own key and certificate decisions. Keep the module list current, export configuration evidence from the systems themselves, and make sure the design documents reflect what is deployed today.

Which open-source tools can produce SC-13 evidence?

Several self-hosted tools can generate parts of the evidence, but none of them proves SC-13 alone. Nextcloud's server-side encryption protects file contents at rest with keys kept on the server, though it does not encrypt file names or folder structure, so you must document that gap. OpenBao's transit secrets engine encrypts and decrypts application data without storing it, supports versioned keys and key rotation, and gives you a record of key use. Wazuh's Security Configuration Assessment checks endpoints against YAML policies, which can confirm that cryptographic settings match your baseline. Fleet's policies answer yes or no questions about devices through osquery, so you can track which hosts pass a crypto-related check. Confirm each tool's validation status with its vendor, because the FIPS validation status of a module matters more than the tool's own license or name.

Which SC-13 parts are commonly outsourced?

Teams most often outsource the cryptographic inventory, the gap review against the chosen baseline, and the build of the evidence set. These tasks need experience across many systems and tend to surface issues that internal teams do not see daily. Decisions about which cryptographic type applies, and the risk acceptance that follows, should stay with the organization. Certification-style judgments belong to an independent assessor, not to an implementation partner. Ask any partner to state in writing which tasks it performs and which remain yours.

Self-hosted open-source tools that support SC-13 evidence

Open-source platforms can produce much of the evidence an assessor examines for SC-13, but each tool covers a different slice of the cryptographic picture, and none of them settles the question of module validation on its own. Start by mapping each cryptographic use in your design documentation to the component that performs it, then decide which tool supplies the configuration or key evidence for that use. Nextcloud server-side encryption (AGPL-3.0-only) protects file contents at rest on local and external storage, with keys held on the server. Its documentation is clear that file names and folder structure are not encrypted. Assessors will ask about that gap, so record it explicitly in your system design documentation along with the compensating decision, such as where sensitive folder names are restricted or whether the storage layer is encrypted separately.

OpenBao (MPL-2.0) fits the key management side of the same design. Its transit secrets engine encrypts and decrypts application data without storing that data, signs and verifies data, and supports versioned encryption keys with key rotation. That gives you a single place to show which keys exist, which version each application uses and when rotation last occurred. Confirm separately whether the cryptographic module underlying your deployment holds a current FIPS 140 validation that covers the algorithms and modes you use. Obtain the module validation certificate and check its listed algorithms against your configuration. OpenBao's features do not establish that status for you, and the same check applies to Nextcloud and any other component in the chain.

Configuration tools then show whether the settings you documented are the settings actually running. Wazuh Security Configuration Assessment (GPL-2.0-only) scans monitored endpoints against YAML policies, mostly based on CIS benchmarks, and can be extended with custom policies that check files, registry keys and running processes. Write a custom policy for your approved TLS versions and cipher settings, and for the permissions on key stores. Fleet (MIT) policies work similarly on devices: each policy is a yes or no osquery question, and the policies page shows which devices pass or fail. Use both as evidence that settings hold over time, and treat a passing result as proof of configuration only, not of cryptographic validation.