CM-14 Signed components: requirements and evidence

What CM-14 signed components requires and why CM-14 is not in any baseline

If you have been told CM-14 applies to your system, you will not find it in any SP 800-53B baseline. CM-14 is not selected for the low, moderate or high baselines or for the privacy baseline, so its presence in your authorization depends on a decision your organization makes, either by tailoring a baseline or by adopting an overlay. The control asks the system to prevent installation of defined software and firmware components unless it verifies that the component is digitally signed with a certificate the organization recognizes and approves. The organization, not the baseline, decides which components fall under that rule and which certificates count as trusted.

The risk is straightforward. Unsigned or altered code can be installed through a build pipeline, a vendor update channel or a manual deployment, and without a verification step nothing stops it from running with the privileges of the component it replaces. CM-14 has two organization-defined parameters, CM-14_ODP[01] and CM-14_ODP[02] in SP 800-53A, which you must set: the components the rule covers and the certificate authorities or signing certificates you approve. Write both down before anyone assesses the control, because an assessor will test against your values, not against a default. The control has no enhancements in Release 5.2.0, so the scope of the work is these two parameters, the enforcement mechanism and the evidence behind them.

Plan the control alongside its related controls: CM-7 (least functionality), SC-12 and SC-13 (key management and cryptographic protection) and SI-7 (software, firmware and information integrity). Confirm with your assessor whether they expect CM-14 evidence to live with your configuration management records or with your integrity controls, since the two often share the same signing keys and logs. Open-source options for issuing and managing the certificates and generating the component inventory that CM-14 depends on are covered in the tooling section of this page.

Which components and teams CM-14 applies to once tailored in

CM-14 does not apply to every file on a system. Once an organization tailors its baseline, it must decide which software and firmware classes count as covered, which systems and environments carry them, which certificate authorities it recognizes, and which vendors supply signed artifacts. Each decision changes the evidence an assessor will ask for.

Defining covered software classes

Start by listing which component types the organization defines as covered: operating system packages, endpoint agents, container images, firmware and vendor updates. CM-14 is organization-defined, so the list must be written down and approved. Check that the definition matches what installation paths actually exist on each system, including manual installs and automated package managers, because an assessor will test the list against real installs.

Scoping firmware and boot components

Firmware, boot loaders and hardware management controllers often install outside the normal software pipeline and may not expose a signature check to the operating system. Decide whether these components fall inside the defined set, and document who can apply firmware updates. Where verification happens in the vendor tooling rather than on the host, record that dependency so the control narrative is accurate.

Selecting in-scope systems and environments

Decide which systems, enclaves and environments must enforce signed-component checks. Production and regulated workloads are the usual starting point, but build, staging and administrative hosts can introduce unsigned code just as easily. Record the boundary in the system security plan and make sure the component inventory under CM-8 reflects the same boundary so the two documents agree.

Recognizing certificate authorities and trust stores

CM-14 depends on the phrase recognized and approved. Name the certificate authorities whose signing certificates the organization trusts, and state where those trust anchors are stored and who can change them. Include any internal CA that issues code-signing certificates, and review whether public roots are accepted at all. An unmanaged trust store is a common gap an assessor will find.

Identifying vendors that supply signed artifacts

List every third party that ships signed software or firmware into the scope, including OS distributors, agent vendors, container image publishers and hardware suppliers. For each, confirm which signing keys they use, how key rotation is communicated and what happens when a signature fails. Your agreements and supplier assessments should describe these terms, since CM-14 evidence often depends on vendor-provided signing data.

Handling exceptions and unsigned components

Some legacy or vendor components will not carry a signature that meets the recognized-authority rule. Decide in advance how such components are approved, compensated or removed, and who signs off the exception. Record each exception with its owner, review date and the compensating control, so the organization can show the decision was deliberate rather than an omission.

How an assessor tests CM-14 under SP 800-53A

This table maps the two CM-14 determination statements in SP 800-53A to the examine, interview and test methods an assessor uses, along with the objects they inspect. Read each row as a question the assessor will ask and the artifact that answers it. The main takeaway is that the assessor needs both a defined list of component classes and a working, recorded verification mechanism, so documentation and a demonstrated control must match.

Assessment element	What the assessor looks for	Typical evidence and common findings
Determination statement 1: defined components	The organization has defined which software and firmware component types the system must block unless signed, and the trusted certificates it recognizes and approves.	Examine the configuration management plan and system component inventory. Finding: component classes are named generically, with no list of firmware or software types covered.
Determination statement 2: enforcement	The system prevents installation of defined components whose digital signature is not verified against an approved certificate.	Test automated tools that verify signatures, such as package managers, firmware update checks or boot verification. Finding: enforcement is documented but not switched on in production.
Examine method	Assessor reviews written artifacts that show the defined component classes, approved certificates and the change control path for adding a new trust anchor.	Change control records showing approval of each trusted certificate. Finding: trust anchors were added during an incident with no recorded approval.
Interview method: signature verification personnel	Staff responsible for verifying digitally signed certificates can explain how they validate a component and what they do on failure.	Assessor asks who approves new certificates and how signature failures are escalated. Finding: responsibility sits with a team that cannot name its procedure.
Interview method: system and network administrators	Administrators can describe how installation is blocked for unsigned components and where exceptions are recorded.	Walkthrough of an install attempt with an unsigned package. Finding: administrators bypass checks with local overrides that nobody reviews.
Test method: automated signature tools	Tools that implement signature checks run in the environment and reject an unsigned or untrusted component during a supervised test.	Test log from a rejected install and a passing install of a signed component. Finding: tool logs are not retained, so the test cannot be repeated.
Scope and related controls	Assessor checks that CM-7, SC-12, SC-13 and SI-7 are consistent with the signing approach for the same components.	Cross-references in the system security plan. Finding: CM-14 is claimed but related key management under SC-12 is undocumented.

Implementing CM-14 in sequence, from defining components to enforcing verification

This sequence turns CM-14 from a policy statement into an enforced rule: the organization decides which components and certificates count, records those choices, and proves that the enforcement point blocks what it should. Each step produces an artifact an assessor can examine, interview against and test.

Define the organization-defined parameters
The control has two organization-defined parameters that the organization must set: which software and firmware components the system must check, and which certificates it recognizes and approves for signing them. The system owner and configuration management lead make these choices with security engineering input, and the output is a written parameter list naming each component class and each approved certificate authority or signing identity. The step is done when every parameter has a value and an owner who can explain why it was chosen.
Record the parameters in the configuration management plan
Write the parameter values, the approval authority for changes to them, and the review trigger into the configuration management plan, so they sit alongside the other configuration items under change control. The configuration management plan is the document an assessor will examine for this control, so the entries must match what the enforcement point actually does. The step is done when the plan is approved and the parameter list has a version number that later changes must reference.
Identify and protect the trust anchors
Confirm which certificate authority or chain each approved signer chains to, and decide whether that trust anchor is an internal CA or an external one. An internal CA can be run with FreeIPA, which includes an integrated Dogtag-based certificate authority, or issue short-lived certificates through the OpenBao PKI secrets engine, which can issue dynamic X.509 certificates so services avoid manual key and signing request handling. Record the root and intermediate certificates, their validity periods and who can sign with them. The step is done when the trust anchor list is in the inventory and the signing keys have restricted access.
Inventory the components in scope
Use the system component inventory and, where available, software bills of materials to list the software and firmware components covered by the parameters. Trivy can identify OS packages and software dependencies in a target and produce them as an SBOM, and OWASP Dependency-Track can consume CycloneDX SBOMs to track components across releases. The output is a list that maps each covered component to its signature source, and a note of any component that arrives without a signature. The step is done when the list reconciles with the inventory and the team has agreed how new components enter it.
Configure the enforcement point to block unverified components
Configure the mechanism that installs or loads covered components, such as package managers, the operating system loader, firmware update tooling or the container runtime, so that it verifies the signature against the approved trust anchors and refuses anything unsigned or signed by an unapproved certificate. The exact settings depend on the platform, so confirm the capability with the vendor or the open-source project before relying on it. The output is a documented configuration file or policy and a change record for it. The step is done when the enforcement settings are under configuration control.
Test the block with a known-bad artifact
Prove the control works by attempting to install a deliberately unsigned component and a component signed by a certificate outside the approved list, then confirming that each attempt is refused and logged. Run the same test after any change to the enforcement point or the trust anchors. Keep the test artifacts, the commands used, the refusal messages and the audit records, since these map to the test and examine methods an assessor will use for CM-14. The step is done when both negative tests fail to install and a positive test with an approved signature succeeds.
Document exceptions and their approvals
Some components will legitimately lack a signature or use an unapproved certificate, such as legacy software or a vendor release in transition. Record each exception with the component, the reason, the compensating measures, the approver, the expiry condition and the review date, and route it through the change control process. The output is an exception register that the enforcement point reflects, so the block is not silently bypassed. The step is done when every exception has an approval on file and the register is reviewed as part of the configuration management plan.

Choosing how signing and certificate issuance are produced in-house

FreeIPA includes an integrated certificate authority based on Dogtag, so an organization that already runs its identity management there can issue and manage certificates from the same system that holds users and hosts. This model suits environments where the organization wants one place to record which certificates it recognizes and approves, and where signing certificates are issued to build teams or release pipelines under a documented approval process. The evidence an assessor usually wants is the CA configuration, the issuance and revocation records, and the list of certificates the organization has approved for signing components.

Recognized authorities: Document which CA certificates the organization trusts for component signing and who approved each one.
Issuance records: Keep logs of signing certificate requests, approvals and issuance, tied to a named owner.
Key custody: Confirm where CA and signing private keys are stored, who can access them and whether hardware protection is available in your environment.
Revocation: Confirm how revoked certificates are published and how installation checks respond to a revoked signer.
Operational burden: The organization carries CA upkeep, patching and backup of the directory service itself.

Confirm with your FreeIPA deployment team which CA capabilities and revocation mechanisms are enabled before you describe them in your system security documentation.

Evidence that passes CM-14 and how to keep it current

CM-14 is tested by looking at what the organization actually allows to install, how it decided which certificates to trust, and what happened when something unsigned arrived. Each artifact below answers one of those questions, and each needs a refresh routine so the evidence still matches the system on the day an assessor asks for it.

Approved certificate list

This is the organization's record of which signing certificates it recognizes and approves for software and firmware. It should name each certificate by subject, issuer, validity period and the owner who approved it, with the approval date. Between assessments, review it on a set schedule, remove certificates that have expired or been revoked, and record every addition with the approval that justified it. An assessor will compare this list against what the enforcement tooling actually trusts, so drift between the two is the first thing to check.

Trust store configuration

The trust store is the technical setting that makes the approved certificate list effective, such as the set of root and intermediate certificates a host or package manager accepts. Export its contents and configuration at each review, then compare the export to the approved list. Any difference should trace to an approved change record. Keep the export under configuration control so changes to the trust store are visible in the same change history as other system settings.

Enforcement policy exports

Export the rules that define which software and firmware components must be signed and which signers are accepted. The export should show the scope of each rule, the defined component types and the verification method. Re-export after every policy change and after every system build, and store each export with a date so that a before and after comparison is possible. A policy that exists only in a console screenshot is hard to defend, so prefer machine-readable exports.

Verification and blocking logs

Logs should show each installation attempt for in-scope components, the signature result, the certificate used, and whether the attempt was allowed or blocked. Sample these logs across the review period, not just the most recent week, and confirm that blocked events were reviewed and routed to the owner of the affected system. Check log retention against the organization's own retention requirements, and confirm that the logging pipeline has not silently stopped for any node in scope.

Rejected unsigned component tests

Test records show that the control blocks what it says it blocks. Maintain a set of test cases with an unsigned package, a package signed by an unapproved certificate and a package signed by an approved certificate, then run them against each system class in scope. Repeat the tests after every change to the enforcement policy, trust store or base image, and keep the dated results with the tester's name. A passing test from a previous build does not show the current build still blocks correctly.

Exception records and interview notes

Each approved exception should name the component, the reason it cannot be signed or verified, the compensating measure, the approver and an expiry date. Review open exceptions at each cycle and close those that have passed their expiry. Interview notes from personnel who verify signatures and from system and network administrators should record what they actually do, which an assessor will test against the procedure. Date the notes, and update them when staff or tooling changes.

How signature verification fits with SBOMs and component inventory

Signature verification at installation is a control point of its own, and it sits next to the inventory evidence that CM-8 asks for rather than replacing it. The practical flow runs from the component inventory to a software bill of materials (SBOM) and then to the installation gate. The inventory records what the system contains. An SBOM generated from the running or built system gives that inventory a machine-readable form, and the installation gate decides whether a new component may enter. An assessor testing CM-14 will want to see that these three pieces agree: the list of components the organization knows about, the approved signing certificates, and the enforcement mechanism that blocks anything outside that set.

Trivy (Apache-2.0) can identify the OS packages and software dependencies in a target and produce them as an SBOM, and it can also scan an existing SBOM. OWASP Dependency-Track (Apache-2.0) consumes and produces CycloneDX SBOMs and VEX, flags components with known vulnerabilities, outdated or modified components and license risk, and tracks license use by SPDX license ID. Used together, they give the organization a repeatable record of what was installed, where it came from and what changed between versions. That record supports the inventory and change evidence auditors commonly request. It does not prove that a component was signed, because an SBOM describes contents and does not verify a signature. Treat the SBOM as input to the review of components, not as the signature check itself.

Confirm how your platform's package manager and installation tooling enforce signatures before you describe CM-14 as met. Ask whether installs are refused when a signature is missing or fails verification, which certificates or keys the tooling trusts, and whether that trust list is documented and approved by the organization. Also confirm whether the enforcement applies to firmware and to updates, not only first-time installs. Where the organization runs its own certificate authority, FreeIPA includes an integrated CA based on Dogtag, and OpenBao's PKI secrets engine can issue X.509 certificates, which may help manage the approved signing certificates. Whether either fits your signing workflow is a decision to make and test in your own environment.

What meeting CM-14 costs in tooling, engineering and evidence upkeep

This table breaks the cost of meeting CM-14 into its components, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to structure a written quote, since no NIST source supplies prices or durations for this control. The main takeaway is that most of the recurring effort sits in maintaining the trust store, the defined parameters and the evidence, not in the initial signing setup.

Cost component	One-time or recurring	What drives it	How open source helps
Certificate authority or key management setup	One-time, with later renewals	Number of signing authorities, whether roots are offline, and the organization's existing PKI	FreeIPA includes a Dogtag-based certificate authority, and OpenBao's PKI secrets engine can issue X.509 certificates, which can remove commercial CA license spend
Enforcement configuration and testing	One-time, repeated after major platform changes	Number of software and firmware component types in scope, and how many package and boot paths must be blocked	Self-hosted tooling can run the verification checks, but the organization still pays for engineering time to configure and test them
Trust store and ODP maintenance	Recurring	Frequency of new signing certificates, revocations and changes to the two organization-defined parameters	Keeping the approved certificate list and parameter values in version-controlled files reduces manual review effort
Evidence upkeep and log review	Recurring	Volume of installation events, how often reviewers sample them, and whether records are kept centrally	Dependency-Track and Trivy can produce component records that support review, though the organization must still review and retain them
External review (optional)	Recurring or per engagement	Scope of the review, whether it covers enforcement tests or only documents, and how often it is repeated	Limited direct effect, since the review fee is paid for independent judgment rather than tooling
Auditor sampling time	Per assessment cycle	Number of components and installation events the assessor samples, and how well records are indexed	Clean, queryable evidence can shorten sampling, but the auditor's fee is set by the auditor

Who owns CM-14 controls, who can build them and what the auditor tests

Your organization owns CM-14 in full. CM-14 has two organization-defined parameters (CM-14_ODP[01] and CM-14_ODP[02] in SP 800-53A), and only your organization can set them. These values define which software and firmware components the system must refuse unless they are signed, and which certificates you recognize and approve as trusted. Those choices belong in your configuration management plan and must be approved by the people accountable for the system.

Parameter decisions: Select the component types in scope and the trusted certificate authorities or signing identities, and record the rationale.
Approval authority: Name who may add or remove a trusted signer and how that change is reviewed under your change control process.
Exception handling: Decide who may approve an unsigned or unverifiable component, for how long, and with what compensating measures.
Interview readiness: Make sure the personnel who verify signed certificates can explain the process to an assessor.
Ongoing review: Schedule periodic review of the trusted signer list and the exception log.

Before engaging anyone else, confirm that these decisions exist in writing and are approved.

Common gaps that fail CM-14 assessments and how to close them

Most CM-14 findings come from decisions that were never written down or never enforced, not from missing tools. The cards below cover the gaps assessors look for first, from undefined parameters to exceptions nobody approved, and the fix for each. Work through them in order, because the parameter values and trust store ownership determine what the other checks can prove.

Undefined organization-defined parameters

CM-14 has two organization-defined parameters (CM-14_ODP[01] and CM-14_ODP[02] in SP 800-53A) that the organization must set. If the system owner has not stated which software and firmware component types are covered and which certificates count as recognized, an assessor has nothing to test against, and the control fails on definition alone. Write both values into the system security and privacy plan and the configuration management plan, name the owner who approved them, and confirm that the enforcement tooling uses the same scope.

Trust store with no named owner

The approved certificates are the trust basis for the whole control, yet many organizations keep them in a file or a vendor portal that no one reviews. Assessors interview the personnel responsible for verifying digitally signed certificates, and a blank answer is a finding. Assign a named owner for adding, renewing and removing signing certificates, record each change through change control, and review the list on a defined schedule so revoked or expired publishers do not stay trusted.

Verification enforced on only some paths

Signature checks often cover the main package manager but miss manual installs, container image pulls, firmware updates, or scripts run by administrators. CM-14 applies to the defined components wherever they enter the system, so a single bypass path undermines the claim. Map every installation route for the defined component types, test each one with an unsigned sample, and record which routes enforce the check and which rely on policy alone.

No evidence that unsigned components were blocked

Configuration files that say verification is on do not prove that an unsigned component was refused. Assessors using the test method look for automated tools that implement signature checks and for records showing the outcome. Keep a repeatable test that attempts to install an unsigned and a signed component on each route, store the logs and the rejected-install events in your audit trail, and retain the results with the assessment package.

Exceptions granted without approval

Teams often need to install a vendor component whose signature is missing or whose certificate has lapsed, and they add a local override to keep work moving. An override with no recorded approval, expiry or compensating control is a deviation the assessor will find in the change records. Route every exception through the change control body, document the component, the risk accepted and the removal date, and check that the override expires automatically or appears in the inventory.

Component inventory that misses signed status

A verification policy cannot be tested if the organization cannot say which components are installed and whether each one carries a valid signature. The system component inventory and the software bill of materials often list names and versions but not signing status, certificate identity or the path each component entered by. Add signer and verification result fields to the inventory and reconcile them against what is actually running, so the assessor can trace each defined component back to a verified signature.

CM-14 questions buyers ask before bringing in outside help

Is CM-14 required if our baseline does not select it?

No baseline selects CM-14 by default, so it is not required unless your organization adds it. SP 800-53B Release 5.2.0 leaves it out of the low, moderate and high baselines and the privacy baseline. You can still add it by tailoring a baseline or through an overlay, and that choice usually follows from your risk assessment, your contracts or the authorizing body's requirements. Confirm with your authorizing official, customer or regulator whether they expect it, because a requirement written into a contract overrides the baseline default. Once you adopt it, you must define the two organization-defined parameters before an assessor can test it.

How much effort does it take to meet CM-14?

Effort depends on how many software and firmware component types you must gate and how many installation paths exist. The control has no enhancements, so the work centers on two defined parameters, the signing certificates you recognize and approve, and the enforcement mechanism that checks signatures before installation. Drivers include the size of your component estate, how many teams publish software, whether firmware is in scope, and whether signing infrastructure already exists. Ask any provider to break its quote into discovery of installation paths, certificate governance, enforcement configuration and evidence collection, and to state which items recur.

Can our team implement CM-14 without an outside partner?

Yes, if your team already runs a certificate authority, controls its package and firmware pipelines and can produce assessment evidence. Many organizations do this internally. Outside help is most useful when signing trust is spread across vendors, when no one owns the list of approved certificates, or when staff lack time to build test evidence. Be clear about roles: your organization owns the control and the approved certificate list, a partner can prepare systems and evidence, and only an independent assessor can report on whether the control is met.

What does the work need from our internal team?

The work needs owners for several roles, and assessors will interview them. You need a person who approves the signing certificates your organization recognizes, engineers who manage package, container and firmware release pipelines, and system and network administrators who control where installation is allowed. Security staff should own the defined parameters and the list of software and firmware types the control covers. Expect to supply your configuration management plan, change control records and the system component inventory, since SP 800-53A lists these as examine objects.

How long does it take to implement CM-14?

No timeline figure is supplied for this control, so do not rely on any duration from a vendor or search result without checking it. The schedule depends on how many installation paths you must cover, whether firmware is in scope, and how much signing infrastructure you must set up or inherit. Ask for a written scope with milestones before work starts, and confirm with your assessor which evidence they will accept and when they plan to test it. Fixed-scope engagements agree deliverables and timelines in writing before work begins.

Can a partner issue the CM-14 evidence or certify our compliance?

No. An implementation partner can configure enforcement, document the parameters and assemble evidence such as test records of blocked unsigned installations. Only an independent auditor, assessor or certification body issues reports or certificates. Your organization remains accountable for the control and must be able to explain its approved certificates and enforcement settings during assessment. Ask any partner to show, in writing, which artifacts it prepares and which artifacts remain your responsibility.

How do CM-14, CM-7 and SI-7 relate to each other?

CM-14 governs whether a component may be installed based on its digital signature. CM-7 limits the software and functions a system provides, so unneeded components are removed or blocked regardless of signature. SI-7 covers integrity verification, which checks that components and information have not been altered after release. The three overlap in practice: a signed component can still be unneeded (CM-7), and an unaltered component can still be unapproved (CM-14). The SP 800-53 catalog names CM-7, SC-12, SC-13 and SI-7 as related controls, so assessors often review them together. Plan your evidence so one set of records can show each control's specific requirement.

Which open-source tools can help meet CM-14?

Open-source tools support parts of the work rather than the whole control. Dependency-Track and Trivy can produce and analyze software bills of materials, which help you inventory components and check their origin. FreeIPA includes an integrated certificate authority based on Dogtag for issuing and managing certificates, and OpenBao's PKI secrets engine issues dynamic X.509 certificates to services. Confirm with each project whether it enforces signature checks at installation, since that enforcement step depends on your platform and is not guaranteed by these tools alone.

Primary NIST sources to confirm CM-14 against

Confirm the CM-14 Signed components requirement first in the CPRT entry for SP 800-53 Release 5.2.0, which shows the control statement with its two organization-defined parameters (CM-14_ODP[01] and CM-14_ODP[02] in SP 800-53A). The parameters are where your organization records which software and firmware components the signature check applies to and which certificates it recognizes and approves. Those two values are the decisions an assessor will ask you to defend, so write them down before anyone else sees the control. Use the NIST CPRT entry for CM-14 as the reference point for the wording, and check it against your own policy.

Use the OSCAL catalog to confirm what the control contains in machine-readable form, including that CM-14 has no control enhancements in Release 5.2.0 and that its related controls are CM-7, SC-12, SC-13 and SI-7. Those related controls matter in practice, because the approved certificate list usually lives in your key and certificate management process and the component inventory under CM-8. Pull the catalog from the usnistgov/oscal-content repository and keep the version tag with your evidence so the ODP values can be traced to a release.

Check baseline selection in the SP 800-53B profiles, where CM-14 is not selected for the low, moderate or high baselines or the privacy baseline. If your system is authorized to one of those baselines, CM-14 is in scope only because you tailored it in, and the tailoring decision must be recorded in your security plan. Confirm this in the SP 800-53B profile files and in the SP 800-53B publication. Ask your authorizing official or assessor whether they expect the control, because a voluntary addition still needs an assessment result.

CM-14 Signed components