CM-10 Software usage restrictions: requirements and evidence

What CM-10 software usage restrictions requires in practice

CM-10 asks the organization to use software and documentation only as its contracts and copyright law allow, to track quantity-licensed software so that copying and distribution stay within the license, and to control peer-to-peer file sharing so it is not used to distribute copyrighted work without authorization. The three parts address different risks: contract and copyright breaches create legal and financial exposure, over-deployment of licensed software creates true-up costs and audit findings, and unauthorized file sharing on managed systems can expose the organization to takedown notices and data leakage. An assessor tests each part separately, so a compliance lead needs evidence for all three, not only a current software list. The difficulty is that license data is scattered. Procurement holds purchase orders and contracts, endpoints hold what is actually installed, and vendor portals hold entitlement and usage counts that may not match either. Before an assessment, confirm which license models apply to each product (per device, per user, per core or subscription), who owns the contract terms, and whether site licenses or enterprise agreements cover the environment you are assessing. Those answers determine what a tracking report must show. One point often causes confusion. The open-source software enhancement, CM-10(1), exists in SP 800-53 Release 5.2.0 but SP 800-53B does not select it for the low, moderate or high baselines, so it is not required by default in those baselines. Your organization may still choose to address open-source license obligations, and an open-source license inventory is a practical way to show that the base requirement is met. Confirm with your assessor or authorizing official whether the enhancement applies to your system.

Which systems and software does CM-10 cover at low, moderate and high baselines?

CM-10 is selected in the low, moderate and high SP 800-53B baselines but not the privacy baseline, so the first scoping decision is which systems fall inside the authorization boundary. Within that boundary, the question becomes which software, licenses and hosted services the organization administers and must track.

Systems inside the boundary

CM-10 applies to the system named in the system security and privacy plan, at whichever impact level the organization assigned. A low, moderate or high categorization selects the control, so the same software rule carries into every system at that level. Systems that hold the privacy baseline only, without a security baseline, need a separate decision. Confirm the categorization in the SSP before listing software.

Commercial and quantity-licensed software

Commercial products sold by seat, core, processor or device count are the core of CM-10's tracking duty. Record the license metric, the entitlement count and the systems where each copy runs. An installation count above the entitlement is the finding an assessor is most likely to test. Include database, virtualization and security tooling, since these often carry quantity limits.

Site-licensed and enterprise agreements

Site licenses and enterprise agreements cover use across a defined population or location rather than a fixed count. Keep the contract, the covered entities and the end-user terms together, because use outside those terms breaches the agreement even when the count looks fine. Confirm which affiliates, contractors or cloud accounts the agreement covers before deploying.

Open-source components

Open-source software is not exempt from CM-10. Each component carries its own license, such as GPL, Apache or MIT terms, and some restrict redistribution or require source disclosure. The open-source enhancement CM-10(1) is not selected in any SP 800-53B baseline, but the organization may still adopt it. Track license IDs for every component, including transitive dependencies.

Endpoints and servers

Workstations, laptops and servers hold most installed software and are where unlicensed or unapproved copies appear. An inventory agent that reports installed software per host gives the evidence base for both quantity counts and copyright checks. Include virtual machines, container images and build agents, since they multiply copies quickly and are easy to miss.

Third-party and hosted software

Software that a cloud provider, managed service or contractor runs for the organization may still fall under its contracts. The organization should confirm who holds the license, who administers it and whether the provider's terms restrict copying or use. Where the organization administers hosted software, it owns the tracking duty for that copy. Record these services in the same inventory as internal systems.

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

This table compares the three assessment methods SP 800-53A applies to CM-10 Software usage restrictions: examine, interview and test. Read each row as what the assessor looks at, who they ask, what they expect to hold, and where organizations typically fall short. The main takeaway is that CM-10 is tested on documented agreements and on a working process for quantity-licensed software, so both need to exist and match.

Assessment method	What the assessor examines or asks	Evidence requested	Common findings
Examine	Software usage restrictions, software contract agreements and copyright laws that govern the system's software	Current contracts, license terms and a written list of software usage restrictions	Restrictions exist only as general policy with no mapping to specific products or contracts
Examine	Site license documentation for software deployed on the system	Site license certificates or agreements matched to installed versions and deployment locations	License documents are out of date or do not cover all installed copies
Examine	Software license tracking reports for quantity-licensed software	Reports showing entitlements, installed counts and reconciliation dates	Reports are missing, or counts differ from what the inventory shows
Interview	Personnel who operate, use and maintain the system, asked how they follow software usage restrictions	Named roles, short written procedures and records of training or briefings	Staff are unaware of restrictions, or describe practices that differ from the documented list
Test	The organizational process for tracking the use of software protected by quantity licenses	A walkthrough of the tracking process, sample reconciliations and records of corrective action	Tracking is informal, with no owner, cadence or record of corrections
Test	Whether peer-to-peer file sharing is controlled so it does not distribute copyrighted work without authorization	Configuration evidence, technical restrictions and monitoring output for file sharing tools	No defined position on file sharing, or no evidence that the stated rule is enforced

How to implement CM-10 in six steps

This sequence moves an organization from an unknown software estate to a documented, evidenced program for CM-10, where each step produces an artifact an assessor can examine, interview staff about and test. The steps run in order because each output feeds the next.

Inventory licensed software and contracts
Start by listing every commercial, subscription and open-source package in use, then match each one to the contract, click-through terms, site license or license file that governs it. Procurement, IT asset management and the owners of major systems usually hold these records, and they often disagree, so reconcile them in one place. Done means you have a license register that names each product, version scope, entitlement type, licensed quantity, governing agreement and business owner. Ask your inventory tooling and procurement teams which sources they treat as authoritative.
Define usage restrictions per license type
For each entry in the register, record what the license allows and forbids: installation scope, number of users or devices, permitted environments, redistribution, reverse engineering, and any use limited to a legal entity or site. Legal or contract staff should review the wording, since copyright and contract terms vary by vendor and by license tier. Done means a restriction list that a technical team can apply, with each rule traced to a clause or license file. Open-source licenses belong on this list too, because their copyleft and attribution duties are restrictions in their own right.
Deploy tracking of installs against entitlements
Configure automated discovery so installed software on endpoints and servers is compared against the entitlements in the register. Self-hosted tools such as GLPI can hold the asset and software records, and an agent such as the Wazuh Syscollector module can report installed software from each endpoint into the Wazuh indexer for dashboard reports. Confirm which fields each tool captures, how often it reports, and whether it can count installations against a quantity-licensed product. Done means a software license tracking report that shows installed counts, entitlement counts and any gap, produced on a schedule you can reproduce.
Set peer-to-peer and unauthorized distribution controls
Decide which file-sharing protocols, peer-to-peer clients and external sharing services are blocked, restricted or monitored on managed systems, and align those rules with the copyright obligations in your restriction list. Enforcement typically combines endpoint policy, network controls and the monitoring from the previous step, and it should cover removable media where your environment allows it. Done means a documented control record that names the blocked or monitored services, the enforcement point for each, the exceptions approved and who approved them. Confirm with your network and endpoint teams which controls are already in place before writing new ones.
Assign ownership and review cadence
Name an accountable owner for the software usage restriction process and an operational owner for the tracking tools. Set a review cadence for the register, the restriction list and the tracking reports, and define what triggers an unscheduled review, such as a new contract, a license true-up, a new open-source component or a change in deployment scope. Written ownership is what an interviewer will test first, because CM-10 assessment involves staff who operate and maintain the system. Done means a signed or approved responsibility record and a calendar entry that the owner can show.
Collect the first evidence set
Run the process once end to end and retain the outputs as a dated evidence package: the license register, the restriction list, the tracking report, the peer-to-peer control records and the ownership and review records. Check that each artifact matches the assessment objects in SP 800-53A for CM-10, so an examiner can trace a determination statement to a document. Done means a folder or repository that an independent assessor can open without help, with a note on any gap that remains open in your plan of action and milestones. Ask your assessor early which format they expect for this evidence.

Why peer-to-peer file sharing and copyright use belong in the same control

CM-10 bundles copyrighted work distribution with license tracking because both answer the same question: what software and content may be copied or shared. A license grants a right to install, run or distribute a product within stated limits, and peer-to-peer file sharing is one of the most common ways those limits get broken without anyone deciding to break them. The control therefore treats unauthorized distribution of copyrighted work and over-deployment of quantity-licensed software as two faces of one governance problem. In practice, the organization owns the decision about which sharing channels are permitted, and the same list of approved and prohibited software usually drives both the license count and the file-sharing rules.

Decide which peer-to-peer channels are blocked, which are allowed for defined business purposes, and which are monitored, then record that decision in the software usage restrictions document and tie each channel to a named owner. Evidence usually includes the written list of restrictions, the firewall or endpoint policy that enforces it, and sample outputs showing blocked or flagged traffic. Because SP 800-53A asks assessors to examine the list of software usage restrictions and the software license tracking reports, the two records should cross-reference each other. Confirm with your own network and endpoint teams which tools actually enforce each channel, since the enforcement point is the part an assessor will test.

The open-source enhancement, CM-10(1), is new in Release 5.2.0 of SP 800-53 and is the only enhancement for this control. The published catalog lists it as not withdrawn, while SP 800-53B does not select it for the low, moderate, high or privacy baselines, so it applies only where an organization or contract chooses to adopt it. Teams that depend on open-source components should read the enhancement's own wording in the NIST catalog before deciding how to address it, and should confirm with their assessor whether it is in scope for their system. Keeping a current component inventory of open-source packages with their license identifiers is the most direct way to support any such evidence.

Evidence that passes a CM-10 review

CM-10 assessments turn on records that show what software is licensed, how it is used and who checks that use. The six artifacts below map to the examine and test objects in SP 800-53A, and each one only holds up if it is refreshed between assessments rather than rebuilt the week before one.

Software usage restriction list

This is the register of which software packages carry usage limits, such as named-user, device, site or quantity terms, and which systems they run on. The assessor checks that the list matches what is actually installed, so compare it against an inventory export rather than a spreadsheet kept by hand. Keep it current by tying each entry to a component record and reviewing additions whenever a new package enters the baseline. Confirm the list also covers open-source components and their license terms.

Software contract and copyright register

This register links each licensed product to the contract, end user license or open-source license that governs it, along with the copyright owner and the permitted use. The assessor looks for evidence that personnel use software in line with those terms, so check that every entry names an owner, a renewal date and the license identifier. Review it at contract renewal and at each change in licensing model. Ask counsel or procurement to confirm the register reflects current agreements.

Site license documentation

Site licenses grant use across a defined location, entity or population, and they often carry conditions on who may run the software and where. The assessor checks the signed agreement against the deployed footprint, including any copies installed outside the licensed site. Keep a dated record of the licensed scope and reconcile it with the inventory each quarter. Where the vendor audits usage, retain the correspondence that shows how the organization responded.

Quantity license tracking reports

For quantity-licensed software, the assessor expects reports that count installed or active copies against purchased entitlements and show how the organization stops copying beyond the limit. Automated reports from the inventory platform are stronger than manual counts, because they show the same method each period. Check that reports record the date, the entitlement, the observed count and the action taken for any overage. Retain prior reports so the trend over time is visible.

Peer-to-peer control configuration and records

Peer-to-peer file sharing is controlled through blocking rules, application allow lists or egress restrictions, and the assessor examines both the configuration and the logs that show it working. Capture the firewall or endpoint policy, the list of blocked applications and any exceptions with approvals. Test the control periodically and keep the test results. Confirm the logs record attempted and blocked connections so the control can be shown to have operated, not just to exist.

Software usage review records

Review records show that someone with authority checked software usage against restrictions and acted on what they found. The assessor looks for dated review minutes, the findings, the owner of each finding and evidence that remediation closed it. Schedule reviews at a defined frequency set by the organization, and record exceptions with their approvers and expiry dates. Confirm that reviews cover both commercial and open-source software, since unreviewed open-source use is a common gap.

What meeting CM-10 costs in money and effort

This table lists the cost components of meeting CM-10 and who is paid for each, marking which ones are one-time and which recur. Use it to frame a quote request, since no figures are published on this page and every amount should come from the organization's written scope and supplier quotes.

Cost component	One-time or recurring	What drives it	How to keep it down
License inventory and reconciliation	Recurring, at each review cycle	Number of products, number of entitlements held in contracts and purchase records, and how many sources must be matched	Keep one agreed list of licensed products and contract terms, and reconcile against it on a fixed schedule
Tracking tooling or licenses	Recurring subscription or support fees, plus one-time setup	Whether the organization already owns an asset or software inventory platform, and how many endpoints or products it must cover	Check whether existing platforms cover the need before buying. Self-hosted open-source inventory tools such as GLPI can remove some license spend, though hosting and support still apply
Engineering time to connect inventory data	One-time integration, then occasional recurring upkeep	Number of data sources (endpoint agents, software catalogs, procurement records, SBOM outputs) and how inconsistent their naming is	Standardize product names and identifiers early, and feed inventory from automated collection rather than manual entry
Evidence upkeep	Recurring	Frequency of reporting, number of systems in scope and how often software changes or is retired	Automate report generation and store reports with dated, versioned records so that refreshing evidence is routine
Internal review and sign-off	Recurring	Number of approvers, whether legal and procurement must review license terms, and how often copyright or contract questions arise	Document decision rules for common cases, such as standard license types, so that only exceptions reach legal review
External review or readiness support	One-time for readiness, optional recurring	Scope of the readiness review, the maturity of existing records and whether an outside party tests the process before the assessment	Ask for a fixed-scope review with written deliverables, and confirm whether the partner prepares evidence or only advises
Auditor sampling and testing	Recurring with each assessment cycle	Number of software products sampled, the number of license records requested and how readily records can be produced	Keep records retrievable by product and date so that sample requests can be answered quickly. Confirm the sampling approach with the independent assessor in advance

Who owns CM-10 and what an outside partner can prepare

Your organization owns CM-10 in full. The control asks that software and documentation be used according to contract terms and copyright law, that quantity-licensed software be tracked, and that peer-to-peer file sharing be controlled. Each of these is an operating decision with a named owner, and an assessor will ask who made the decision, where it is recorded and who checks it. No outside party can accept the license risk on your behalf.

License register: Your team keeps the authoritative list of licenses, entitlement counts, contract terms and renewal dates, and names one accountable owner for it.
Usage restrictions: Legal, procurement and security staff interpret vendor agreements and open-source license obligations, then decide which restrictions apply to which products.
Quantity tracking: Your team defines how installed copies are compared with purchased entitlements and how often that comparison runs.
File sharing rules: Your team sets the policy for peer-to-peer tools on managed endpoints and approves any exception in writing with an expiry date.
Evidence sign-off: Your team owns the policy, procedures, exception records and reviews that the assessor will sample.

Check that every role above has a named person, that the license register is reviewed on a schedule you can show, and that exceptions are not left open indefinitely.

Where CM-10 programs usually fall short

CM-10 programs tend to fail on records rather than intent. The licenses exist, the policies exist, but the register, the install data, the file-sharing logs and the open-source review do not agree with each other or survive past the assessment day. The cards below name the gaps an assessor is most likely to find and the check that closes each one.

No single license register

Quantity-licensed software often sits across procurement files, vendor portals, finance records and individual administrators' spreadsheets. An assessor testing CM-10 will ask for one list of software usage restrictions and license tracking reports, and a split register makes it hard to show that copying and distribution are controlled. Ask who owns the consolidated list, where each license term is recorded, and whether the list is reviewed on a defined schedule.

Install data that does not match entitlements

Inventory tools may show more installations than the purchased seats, or installations that no contract mentions at all. Without comparing discovered software against license records, the organization cannot show that its use stays within contract agreements. Check whether installed software collected from endpoints is reconciled to entitlements, and document how each variance is resolved or escalated.

Peer-to-peer controls with no records

Many organizations block or restrict peer-to-peer file sharing in policy but cannot show the control operating. CM-10 expects the organization to prevent that channel from distributing copyrighted work without authorization, and an assessor will look for configuration evidence and any logged exceptions. Confirm which tool or network control enforces the restriction, how it is configured, and where denied or approved exceptions are recorded.

Open-source components with unchecked licenses

Open-source components reach production through application dependencies, container images and operating system packages, and their license terms are rarely reviewed at intake. CM-10 assessors may ask how the organization knows which license applies to each component in use. Generate a software bill of materials for each system, record license identifiers, and confirm that copyleft or restrictive terms have been reviewed by someone with the authority to accept them.

Evidence current only on audit day

Some programs assemble license reports, file-sharing exception lists and software inventories just before an assessment, then let them drift. The assessment procedure for CM-10 looks at tracking processes in operation, so a snapshot without a history of how it was produced will not show ongoing control. Set a recurring export and review of the register and inventory, keep dated copies, and record who reviewed each one and what changed.

How much work does CM-10 take, and can we do it ourselves?

Can our own team meet CM-10 without outside help?

Yes, in most organizations the owning team can meet CM-10 in-house, because the control asks for discipline rather than new technology: software is used under its contract terms, license use is tracked, and peer-to-peer file sharing is controlled. The harder part is consistency across the estate. Teams that already run a software inventory, a license register and an acceptable use policy have most of the building blocks. Teams without them usually need help building a current record of what is installed, which licenses cover it and who is responsible for each agreement. Your staff still owns the decisions, and an independent assessor still decides whether the evidence passes.

What drives the effort and cost of meeting CM-10?

The main drivers are the size and variety of the software estate, how many license agreements exist, and how much of the license data is held in spreadsheets or in people's heads. Other factors are the number of systems in scope, whether quantity-licensed products are deployed across many endpoints, and how far peer-to-peer file sharing is allowed in the environment. Costs fall into two groups. One-time costs cover the initial reconciliation of licenses against installations, policy writing and tool setup. Recurring costs cover periodic license reviews, inventory upkeep and evidence collection for each assessment cycle.

What does the work require from our teams?

The work needs three groups of people. Procurement and legal must hold the software contracts and know which usage terms apply. IT operations must provide a reliable record of installed software and its locations. Security or compliance must define the policy, set review frequency and collect the evidence. Engineers will spend time on inventory collection and on setting up any open-source tooling, while business owners confirm which licenses they need. Expect the most friction where ownership of license agreements is unclear, so name an accountable owner for each major product before work starts.

How long does CM-10 take to implement?

No researched duration applies to CM-10, so confirm timing with your assessor and with any partner you consider. The schedule depends on how many license agreements must be reconciled, how complete the current software inventory is, and how many business units hold their own contracts. A first pass usually takes longer than later reviews, because the initial reconciliation is the slowest step. Ask any provider to break the timeline into phases with named deliverables, and ask which of those phases depend on your procurement and legal teams responding.

Does NIST publish a cost estimate for CM-10?

No. NIST does not estimate compliance or certification costs for SP 800-53 controls, and it does not set implementation timelines for federal agencies, which it leaves to OMB Circular A-130. Any cost figure you see for CM-10 must come from a vendor, consultant or your own estimate. When you request a quote, ask for the cost components separately: discovery and reconciliation, policy and procedure work, tooling, evidence collection and assessor fees. Also ask which items are one-time and which recur each year, so the budget reflects the full lifecycle.

When should we bring in an implementation partner for CM-10?

Bring in a partner when the software estate is too large or fragmented for your team to reconcile in a reasonable period, when license data is incomplete, or when you need open-source tooling deployed and integrated in your own environment. DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure and prepares evidence for compliance assessments. It works under a written, fixed scope, and it does not issue audit reports or certifications. An independent auditor or assessor makes that determination. A partner also makes sense if you lack staff to maintain the tooling after handover.

How GLPI, Wazuh, Dependency-Track and Trivy produce CM-10 evidence

Four open-source tools cover different parts of the CM-10 evidence picture, and none of them replaces the license records an assessor will ask to see. GLPI supplies the software side of the asset record. Its Assets module tracks software alongside computers and other equipment, and the GLPI Agent can push installed software automatically through native inventory, which is available in GLPI since version 10. Use the software and license entries in GLPI as the list of what is installed and where, then attach the site license documentation, contract terms and quantity counts that the assessor will examine for the quantity-licensed software you run.

Wazuh Syscollector covers endpoints. It collects installed software, operating system details, services and Windows updates from each agent and stores them in the Wazuh indexer, where the dashboard can produce inventory views and reports. This gives you evidence that unauthorized or unlicensed software is visible on the machines that matter, and it can show whether a deployed package matches the approved list. Confirm that the agents cover every in-scope population, including servers and administrative workstations, because a gap in agent coverage becomes a gap in the evidence.

Dependency-Track addresses the open-source license side. It consumes and produces CycloneDX SBOMs and tracks license use by component using SPDX license IDs, so it can flag license risk across the components in your applications. Trivy identifies OS packages and software dependencies in a target and can export them as an SBOM, or scan an SBOM you already hold, which feeds Dependency-Track. Note that GPL-licensed components such as GLPI (GPL-3.0-or-later) and Wazuh (GPL-2.0-only) carry copyleft obligations if you modify and distribute them, so have counsel confirm the license terms fit how your organization uses and distributes each tool before you rely on them as evidence.

CM-10 Software usage restrictions