SC-13, Cryptographic Protection, asks the organization to determine the cryptographic uses it has, and to implement the types of cryptography required for each use. Both lists are organization defined. So the control is only as precise as your own write up.
800-53 binds US federal systems, and others through contract. For small and mid size companies it is a reference. If you sell to government, or to customers who flow down FIPS requirements, you may meet it in a contract.
What it means in practice
The guidance says cryptography supports several things: protecting classified and controlled unclassified information, digital signatures, information separation, and random number and hash generation. Generally applicable standards include FIPS-validated cryptography and NSA-approved cryptography. A group needing digital signatures may specify FIPS-validated cryptography. Implementation follows applicable laws, directives and standards.
The enhancements show the options: SC-13.1 FIPS-validated Cryptography, SC-13.2 NSA-approved Cryptography, SC-13.3 Individuals Without Formal Access Approvals and SC-13.4 Digital Signatures.
Two steps are hidden in the sentence. First, find every place you use cryptography. Second, set the requirement for each and make sure the implementation meets it. Teams often skip the first one.
A typical inventory covers data in transit, data at rest, password hashing, code and artifact signing, token signing, and random number generation.
Evidence to collect
- A cryptographic use inventory: use, algorithm, key length, library or service, owner.
- The standard you require for each use, such as FIPS-validated modules where a contract demands them.
- Configuration exports: TLS settings, disk and database encryption status, storage encryption settings.
- Module validation references when you claim FIPS validated cryptography.
- Scan or test results showing weak algorithms are not in use.
Common gaps
No inventory, so nobody knows whether an old algorithm survives in a corner of the code.
Claiming FIPS compliance because the algorithm is approved, when the contract wanted a validated module. Those are different statements.
Homegrown cryptography, or a standard algorithm used in an unsafe mode.
Cryptographic libraries inside dependencies that no one tracks. Scanning dependencies, for instance with the free in browser scan at gold.safeguard.sh/scan, helps you see which libraries you carry.
How to implement it
- Build the inventory from code search, configuration review and architecture diagrams.
- For each use, write the required algorithm, key size and module standard.
- Compare actual configuration against the requirement and fix drift.
- Retire weak algorithms on a dated schedule.
- Check key handling under SC-12, because strong algorithms with poor key management still fail.
- Re-run the inventory yearly and after major dependency changes.
What an auditor may ask
- Show your inventory of cryptographic uses.
- Which standard applies to each, and who decided?
- How do you know no weak algorithm remains in production?
An inventory with a review date answers most of this in one document.
Quick check
What is the first step many teams skip?
Determining every cryptographic use in the first place. The control asks you to define the uses before implementing the types.
Is an approved algorithm the same as FIPS-validated cryptography?
No. Algorithms and cryptographic modules are validated separately. Check which validation your contract or customer requires.
