Quick-reference card
| Field | Value |
|---|---|
| Control ID | CM-14 |
| Control Name | Signed Components |
| Framework | NIST SP 800-53 Rev 5 |
| Control Family | Configuration Management |
| Baselines | Not part of any baseline |
| Relevance | First Party and Third Party (Organization and System Level) |
| Risk Severity | High |
What this control requires
CM-14 requires organizations to block installation of software and firmware unless each component carries a valid digital signature from an approved certificate. This control targets a gap most teams overlook: the assumption that components arriving through trusted channels are inherently safe.
In practice, this means you need a defined list of approved signing certificates, a technical enforcement mechanism that checks signatures before installation, and a process for maintaining and updating that approved certificate list. The scope covers version updates, patches, service packs, device drivers, and basic input/output system (BIOS) updates. That scope covers essentially any software or firmware that modifies the operating state of a system.
That scope wasn’t always treated as its own control. CM-14 is new to Revision 5 of NIST SP 800-53, consolidating what was formerly addressed as an enhancement under CM-5(3) in Revision 4. The elevation to a standalone control reflects a growing recognition that unsigned or improperly signed components represent a distinct and serious threat category, not merely a subset of access restrictions for configuration changes.
Why it matters
Most organizations invest heavily in perimeter defenses and access controls while leaving component integrity verification as an afterthought. Unsigned software and firmware create a direct path for malicious code to enter production systems, bypassing every other security layer you’ve built.
Failure to maintain this control introduces audit risk and may result in certification withdrawal or regulatory findings. Auditors assessing your configuration management program will look specifically for evidence that component signing is enforced, not just documented. Without that evidence, you face findings that can stall authorization to operate (ATO) decisions and erode confidence from oversight bodies.
The risk compounds in environments with complex supply chains. When your organization accepts components from multiple vendors, each integration point becomes a potential insertion vector for tampered code. A single unsigned driver or unverified firmware update can compromise system integrity across your entire environment.
Beyond compliance, the operational consequences are tangible. Tampered components can introduce persistent backdoors that survive reboots and reimaging, making incident response significantly more difficult and expensive.
Where enforcement gaps exist, these are the attack vectors that become most accessible:
- Supply chain compromise. Injecting malicious code into legitimate software or firmware updates before they reach your environment
- Counterfeit drivers. Distributing unsigned or fraudulently signed device drivers that install rootkits or keyloggers at the kernel level
- BIOS and firmware tampering. Modifying low-level firmware to establish persistence below the operating system, evading standard endpoint detection
- Certificate spoofing. Using stolen or fraudulently obtained code-signing certificates to make malicious components appear legitimate
- Update channel hijacking. Intercepting or redirecting update mechanisms to deliver altered components that pass superficial integrity checks
How to implement
The biggest implementation challenge with CM-14 isn’t the cryptographic verification itself. It’s building and maintaining an accurate, current inventory of approved signing certificates across every component category in your environment.
For your organization
Start by cataloging every software and firmware component type that your systems consume. This includes operating system patches, application updates, device drivers, BIOS and Unified Extensible Firmware Interface (UEFI) firmware, and service packs. Without a complete inventory, you can’t define what “approved” means.
Once your inventory is complete, define and document your approved certificate list. This should specify which certificate authorities (CAs) and individual signing certificates your organization recognizes for each component category. A BIOS update from your hardware vendor requires a different certificate chain than an application patch from a software provider. Maintain this list as a living document with clear ownership and a review cadence.
With your certificate list in place, configure your systems to enforce signature verification before installation. On Windows environments, this involves code integrity policies and Windows Defender Application Control (WDAC). On Linux systems, you can enforce package signature verification through package manager configurations. For firmware, Secure Boot and platform-specific integrity verification tools provide enforcement at the hardware level.
Beyond configuration, establish a process for handling signature verification failures. When a component fails verification, your team needs a documented workflow that includes quarantining the component, notifying the appropriate stakeholders, and investigating before any manual override occurs. Every override should require approval from a designated authority and generate an auditable record.
Common mistakes to avoid:
- Allowing broad certificate trust that accepts any certificate from a major CA rather than pinning to specific, approved signing certificates
- Failing to update the approved certificate list when vendors rotate their signing certificates, which causes legitimate updates to be blocked
- Implementing signature checks in monitoring-only mode indefinitely without transitioning to enforcement
- Overlooking firmware and BIOS components, focusing only on software packages
For your vendors
When assessing your vendors’ compliance with CM-14, you need to verify that they enforce component signing throughout their own environments and within the components they deliver to you.
Specifically, request evidence that your vendor maintains a documented list of approved signing certificates. Ask specifically how they handle certificate lifecycle management, including rotation, revocation, and emergency replacement procedures. A vendor who can’t articulate their certificate governance process likely doesn’t have a mature one.
To dig deeper, include the following questions in your vendor security assessments:
- Does your organization digitally sign all software and firmware components before distribution?
- What certificate authorities issue your code-signing certificates, and how do you protect the associated private keys?
- How do you verify the integrity of third-party components that you incorporate into your products?
- What is your process for revoking and replacing compromised signing certificates?
- Do your systems enforce signature verification before installing updates, patches, and firmware?
Red flags to watch for include vendors who cannot produce a current certificate inventory, those who rely on self-signed certificates without a documented trust chain, and any vendor whose update distribution mechanism does not enforce signature verification at the client endpoint.
In practice, you should also request specific artifacts as evidence: their configuration management policy sections addressing code signing, their certificate management procedures, and records of recent signature verification audits. If a vendor provides components to your environment, validate that those components are signed with certificates your organization has independently verified and approved.
Evidence examples
| Evidence Type | Example Artifact |
|---|---|
| Configuration management policy | Policy document defining requirements for digital signatures on all software and firmware components, including approved certificate authorities and component categories subject to signing |
| Certificate management procedures | Documented procedures for issuing, approving, rotating, and revoking code-signing certificates, including the designated approval authority |
| System security plan | Security plan sections specifying which software and firmware component types require signature verification and the enforcement mechanisms in use |
| System design documentation | Architecture diagrams and configuration specifications showing where and how signature verification is enforced across system components |
| Change control records | Records of component installations showing signature verification status, including any override approvals and their justifications |
| System component inventory | Inventory listing all software and firmware components subject to CM-14 signature requirements, mapped to their approved signing certificates |
Cross-framework mapping
No applicable cross-framework mappings have been configured for this control.
Related controls
- CM-07, Least Functionality. Restricting system functionality to essential components reduces the number of software and firmware items that require signature verification under CM-14.
- SC-12, Cryptographic Key Establishment and Management. Governs how your organization manages the cryptographic keys underlying the digital certificates that CM-14 relies on for component verification.
- SC-13, Cryptographic Protection. Defines the approved cryptographic algorithms and standards that the digital signature mechanisms enforced by CM-14 must use.
- SI-07, Software, Firmware, and Information Integrity. Provides the broader integrity verification framework that CM-14 supports by specifically targeting pre-installation signature checks on components.
- SA-22, Unsupported System Components. Addresses the risk of running unsupported components that may no longer receive signed updates, creating gaps in the signature verification chain that CM-14 establishes.
Frequently asked questions
What is NIST SP 800-53 CM-14
CM-14 is a configuration management control that requires organizations to prevent the installation of software and firmware components unless each component has been digitally signed with an organizationally approved certificate. It was introduced as a standalone control in Revision 5, replacing the former CM-5(3) enhancement from Revision 4. The control applies to all component types, including patches, drivers, BIOS updates, and service packs.
What happens if CM-14 is not implemented
Without CM-14, your organization has no systematic mechanism to verify that software and firmware components are authentic and untampered before installation. This gap exposes your systems to supply chain attacks, counterfeit drivers, and compromised firmware updates that can establish persistent footholds below the operating system level. Auditors will flag the absence of component signing verification as a configuration management deficiency, which can delay or block authorization to operate decisions.
How do you audit CM-14
Auditors assess CM-14 by verifying that your organization maintains a documented list of approved signing certificates and that your systems enforce signature verification before installing software and firmware components. They will examine change control records to confirm that installations include signature verification results and that any override of a failed verification has documented approval. Testing typically involves attempting to install an unsigned or improperly signed component to confirm that the enforcement mechanism blocks it.
What types of components require digital signatures under CM-14
CM-14 applies to any software or firmware component that modifies the operating state of a system, including version updates, patches, service packs, device drivers, and BIOS or UEFI firmware updates. Organizations can define which specific component types fall under this requirement, but the control’s intent covers both software packages distributed through update channels and firmware delivered directly to hardware. The key criterion is whether installing the component could alter system behavior without detection if left unverified.