CM-10: Software Usage Restrictions

Quick-reference card

What this control requires

CM-10 requires organizations to enforce software usage restrictions aligned with licensing agreements and copyright laws. It’s one of the few NIST SP 800-53 controls that directly addresses the gap between what software people install and what the organization has actually authorized and paid for.

What distinguishes CM-10 from other configuration controls is how directly it maps to legal exposure. All software and its associated documentation must be used in accordance with contract agreements and copyright laws. Organizations must also track software protected by quantity licenses to prevent unauthorized copying, and they must control peer-to-peer (P2P) file sharing to prevent unauthorized distribution of copyrighted work.

What makes CM-10 operationally significant isn’t the legal compliance angle alone. Untracked software creates blind spots in your security posture. Every application that falls outside your managed inventory is an application that doesn’t get patched, doesn’t get scanned, and doesn’t show up in your incident response playbook. That gap between your documented software environment and your actual software environment is exactly where risk accumulates.

Why it matters

Most organizations treat software usage restrictions as a procurement concern, not a security one. That’s a mistake. When employees install unlicensed tools, trial software, or peer-to-peer clients to get their work done, they’re creating an entire shadow software estate that sits outside every security control you’ve built.

These unmanaged applications don’t appear in your endpoint inventory. They aren’t enrolled in enterprise patch management. Vulnerability scanners don’t know they exist, and endpoint detection tools can’t monitor what was never in scope. The result is a growing collection of software with known vulnerabilities, no update path, and no visibility.

The problem scales faster than most security teams realize. Every new hire and every contractor onboarding comes with pressure to install whatever tool gets the job done, and deadline-driven projects amplify it further. Without technical enforcement, your approved software list becomes aspirational rather than authoritative.

Attackers understand this gap and actively exploit it. Trojanized versions of popular unlicensed utilities retain full functionality while embedding backdoors.

A user trusts the software because it works exactly as expected. Your security team can’t detect it because it was never part of the managed environment.

The attack chain is well-documented in MITRE ATT&CK. Software arriving outside sanctioned channels bypasses code-signing verification (T1553 - Subvert Trust Controls). Peer-to-peer clients introduce T1550.001 (Application Access Token) risk, where attackers reuse OAuth tokens stored in non-standard, unmonitored locations by applications installed outside enterprise identity management. End-of-life or unsupported software often lacks the telemetry hooks that modern detection tools rely on, allowing attackers to operate undetected through indicator blocking (T1562.006).

What attackers exploit:

• Unlicensed software with embedded malware that retains legitimate functionality, making user-side detection nearly impossible
• Unpatched applications outside enterprise update cycles, exposing known vulnerabilities indefinitely
• Peer-to-peer clients that expose file system contents and authentication tokens to external networks
• Trial or freemium tools that request elevated permissions during installation, expanding the attack surface beyond what the user intended
• Shadow IT file-sharing services that bypass data loss prevention controls and create unmonitored exfiltration paths

From a compliance perspective, the consequences extend beyond security risk. Federal agencies and contractors face audit findings and potential loss of authorization to operate. Commercial organizations risk software license violations that carry significant financial penalties, particularly with enterprise vendors who conduct periodic license audits of their customer base.

How to implement

The most common failure mode for CM-10 isn’t a lack of policy. It’s a policy that exists on paper while the actual software environment drifts further from it every quarter. Effective implementation requires both technical controls and operational processes that keep your software inventory aligned with what’s actually running in production.

For your organization

Start with a complete software inventory. You can’t enforce restrictions on software you don’t know about. Deploy endpoint agents or agentless scanning that discovers installed applications across every endpoint, server, and virtual machine. Reconcile this inventory against your approved software list and license entitlements at least quarterly.

Build and maintain a formal approved software list that specifies which applications are authorized, which versions are permitted, and what license quantities you hold. Make this list accessible to IT service desk teams so they can validate requests before installation.

Implement application allowlisting or software restriction policies that prevent unauthorized installations. This is where most organizations struggle, because overly restrictive policies create friction and drive shadow IT. The key is pairing technical controls with a streamlined exception request process so employees don’t feel forced to work around the system.

For quantity-licensed software, deploy a software asset management tool that tracks installations against entitlements. Manual spreadsheets fall apart at scale. Automated tracking catches over-deployment before it becomes a compliance finding and gives you evidence for auditors.

Document your peer-to-peer file sharing policy explicitly. Most organizations ban it entirely; others permit specific tools under controlled conditions. Either approach works if it’s documented, communicated, and technically enforced. Network-level controls that block P2P protocols are more reliable than policy alone.

Create a clear process for handling policy violations. When unauthorized software is discovered during a scan, you need a defined workflow for who gets notified, how quickly the software must be removed or approved, and how the incident gets documented. Without a consistent response process, enforcement becomes arbitrary and employees stop taking the policy seriously.

Establish a regular cadence for reviewing and updating your approved software list. Applications get deprecated, vendors get acquired, and new tools emerge constantly. A list that hasn’t been reviewed in six months is almost certainly out of date.

Common mistakes to avoid: treating software usage restrictions as a one-time project rather than continuous compliance monitoring, failing to include contractor and remote endpoints in your scanning scope, and relying solely on honor-system policies without technical enforcement.

For your vendors

When evaluating third-party vendors against CM-10, you’re assessing whether they have the same rigor over their software environment that you maintain over yours. A vendor with uncontrolled software usage introduces risk that flows directly into your supply chain.

A vendor’s software usage discipline is a meaningful indicator of their overall security maturity. Start your assessment with targeted questionnaire questions:

• Do you maintain a documented software usage and licensing policy?
• How do you track software installations against license entitlements?
• What technical controls prevent unauthorized software installation on systems that process our data?
• Do you restrict or monitor peer-to-peer file sharing on your corporate network?
• How frequently do you reconcile your software inventory against authorized applications?

Policies alone don’t demonstrate compliance. Request specific evidence beyond policy documents. Ask for a recent software license reconciliation report, a copy of their approved software list, and documentation of their application control or allowlisting configuration. If they use a software asset management tool, ask for a summary dashboard export that shows license compliance status.

Watch for red flags during the evidence review. Vendors who can only produce a policy document but no technical evidence of enforcement are likely operating on trust alone. Vendors with no software asset management tooling in environments with more than 50 endpoints are almost certainly out of compliance. A vendor who claims P2P restrictions but can’t describe how they enforce them at the network or endpoint level is another concern. Also be wary of vendors who provide license counts that don’t match their reported headcount or device inventory.

Verification goes beyond the initial assessment. Include CM-10-related questions in your periodic vendor reassessment cycle. Software environments change constantly, and a vendor who was compliant 12 months ago may have drifted significantly since then.

Pay particular attention to vendors undergoing rapid growth or organizational change. Mergers, acquisitions, and workforce scaling events are exactly when software usage controls tend to break down, as new employees bring their own tool preferences and legacy systems get absorbed without proper inventory reconciliation.

Evidence examples

Auditors draw from the assessment objectives in the NIST SP 800-53 catalog and the evidence objects below when evaluating CM-10 compliance.

Cross-framework mapping

Related controls

• AC-17 (Remote Access). Remote access expands the perimeter where unauthorized software can be installed, making CM-10 enforcement more difficult on unmanaged or partially managed endpoints.
• AU-06 (Audit Record Review, Analysis, and Reporting). Audit log analysis can detect unauthorized software installations and P2P activity that CM-10 policies are designed to prevent.
• CM-07 (Least Functionality). Least functionality restricts system capabilities to only what’s required, complementing CM-10 by limiting the software that can run on a given system.
• CM-08 (System Component Inventory). A complete component inventory is the foundation for CM-10 enforcement. You can’t restrict software usage without knowing what’s installed.
• PM-30 (Supply Chain Risk Management Strategy). Supply chain risk management addresses the broader ecosystem of software sources, ensuring that software entering the organization meets security and licensing requirements.
• SC-07 (Boundary Protection). Boundary controls can enforce CM-10 at the network level by blocking unauthorized P2P protocols and preventing software downloads from unapproved sources.

Frequently asked questions

What is NIST SP 800-53 CM-10?

CM-10 is the NIST SP 800-53 control that requires organizations to enforce software usage restrictions aligned with contract agreements, copyright laws, and organizational policy. It specifically addresses tracking quantity-licensed software and controlling peer-to-peer file sharing to prevent unauthorized distribution. CM-10 appears in all three baselines (LOW, MODERATE, HIGH), making it a universal requirement across federal information systems and organizations that adopt the framework.

What happens if CM-10 is not implemented?

Without CM-10 controls, organizations lose visibility into what software is actually running in their environment, creating blind spots that attackers exploit with trojanized unlicensed utilities and unpatched applications. Software license tracking becomes reactive rather than proactive, leading to non-compliance findings during audits and potential legal exposure from copyright violations. Peer-to-peer file sharing goes unmonitored, opening paths for unauthorized data distribution. The operational impact compounds over time as unmanaged software accumulates, expanding the attack surface while remaining invisible to vulnerability scanners and endpoint detection tools.

How do you audit CM-10?

Auditing CM-10 starts with examining the configuration management policy, software usage restrictions documentation, and software license tracking reports to verify that requirements are defined and actively enforced. Assessors compare the approved software list against actual endpoint inventory data to identify unauthorized installations. They also review P2P file sharing controls for both policy documentation and technical enforcement at the network and endpoint level. The most reliable audit evidence combines automated software asset management reports with periodic reconciliation records that demonstrate ongoing compliance rather than a point-in-time snapshot.

Does CM-10 apply to open-source software?

Yes. While CM-10’s primary focus is on commercially licensed software, the control’s language covers all software used within organizational systems, including open-source tools. The CM-10(1) enhancement specifically addresses open-source software by requiring organizations to establish restrictions on its use and to track compliance with open-source license obligations. Many open-source licenses (GPL, LGPL, AGPL) carry distribution and attribution requirements that are just as binding as commercial contract agreements, making software license tracking essential even when the software itself is free. Organizations should maintain an open-source inventory alongside their commercial software asset management processes.