SA-6: Software Usage Restrictions

SA-6 (Software Usage Restrictions) requires you to define and enforce what software is allowed, prohibited, and conditionally approved in your environment, then prove those restrictions are operating in practice. Operationalize SA-6 by setting usage rules (by system, user role, and data sensitivity), implementing technical controls to prevent unauthorized software, and retaining auditable evidence of enforcement and exceptions. ¹

Key takeaways:

• You need explicit software “allow/deny/conditional” rules, not a generic acceptable use policy. ¹
• Enforcement must be technical where feasible (application allowlisting, endpoint controls, packaging controls), backed by exceptions and monitoring.
• Auditors will ask for proof: inventories, allowlist baselines, blocks/preventions, approvals, and exception tracking tied to assets and owners.

SA-6 sits in the System and Services Acquisition (SA) family, but it becomes operational in endpoint management, server hardening, cloud governance, and CI/CD. The core problem it addresses is simple: if teams can install or run whatever they want, you inherit license risk, security risk (unvetted binaries, trojans, unsigned packages), and supportability risk (undocumented dependencies, inconsistent builds). A written policy helps, but SA-6 expects restrictions you can actually execute and audit.

For a CCO, GRC lead, or security compliance owner, the fastest path is to treat SA-6 as a bounded “software governance” control with three outputs: (1) documented restrictions (what’s allowed and under what conditions), (2) technical enforcement aligned to those restrictions, and (3) evidence that shows the restriction model is operating continuously, including how you handle exceptions. The most common failure mode is vague language (“only approved software may be used”) without a real approved list, without enforcement, and without traceable exception decisions.

This page gives you a requirement-level implementation runbook: scope, owners, step-by-step tasks, evidence bundles, audit questions, and a practical execution plan you can run through your existing ITSM, endpoint management, and change management processes. ¹

Regulatory text

Control: “SA-6: Software Usage Restrictions.” ²

What the operator must do: Implement documented restrictions on software usage and make those restrictions real through governance and technical controls. In practice, that means you define which software is approved, which is prohibited, and which requires conditional approval; you enforce those rules on the systems in scope; and you keep evidence that the control is working over time. ¹

Note: The provided excerpt is the control identifier itself (“NIST SP 800-53 control SA-6.”). Use the official NIST SP 800-53 Rev. 5 publication and catalog as the authoritative source for the full control statement and any related discussion. ³

Plain-English interpretation (what SA-6 really means)

SA-6 means you run a “default deny unless approved” program for software in environments where you care about security and compliance. “Software” includes desktop apps, server packages, agents, scripts, browser extensions, containers/base images, and CI/CD dependencies when they end up running in production or on managed endpoints.

A workable interpretation:

• You maintain a software allowlist baseline for each environment (end-user endpoints, build runners, production servers, privileged admin workstations).
• You block or tightly control unauthorized execution/installation.
• You require review and approval for new software and for meaningful changes (publisher change, major version bump, new privileges, new network access).
• You track exceptions with an owner, business justification, compensating controls, and an expiration or periodic re-approval.

Who it applies to (entity and operational context)

SA-6 applies to organizations implementing NIST SP 800-53 controls, including:

• Federal information systems.
• Contractor systems handling federal data, where 800-53 is incorporated via contract, ATO requirements, or a customer security baseline. ¹

Operationally, you should apply SA-6 wherever software can be introduced outside controlled pipelines:

• Corporate endpoints (Windows/macOS/Linux)
• Servers (on-prem and cloud)
• Virtual desktops and privileged access workstations
• CI/CD runners and build agents
• Container platforms (base images, runtime packages)
• SaaS environments where apps/plugins/extensions can be installed by users or admins

What you actually need to do (step-by-step)

1) Define scope and outcomes (make SA-6 auditable)

Create a one-page SA-6 control card:

• Objective: restrict software usage to approved software; prevent unauthorized installs/exec; manage exceptions
• In-scope assets: endpoint groups, server tiers, cloud accounts/subscriptions, build runners
• Out-of-scope (temporarily): legacy systems with a dated remediation plan
• Control owner: usually Security Engineering + IT Ops; GRC owns oversight
• Cadence: continuous enforcement; periodic review (set a cadence you can meet) This is the fastest way to prevent “policy-only compliance.” ²

2) Build an approval model that operators will follow

Define three categories:

• Approved: allowed to install/run, with standard configurations
• Prohibited: never allowed (examples: unlicensed software, known high-risk remote admin tools unless explicitly approved, unauthorized crypto miners)
• Conditional: allowed only for specific roles, systems, or projects (e.g., packet analyzers on admin workstations, developer tools only on dev endpoints)

Also define approval triggers:

• New title/vendor/publisher
• New major version
• Requests for elevated privileges, kernel drivers, browser extensions, or always-on network access
• Software that touches regulated data or authentication flows

3) Create and maintain the approved software baseline

Produce an Approved Software Register with:

• Software name, publisher, purpose
• Approved versions (or version constraints)
• Allowed platforms (Windows/macOS/Linux, server, container)
• Approval authority (named role)
• Packaging source (MDM package, SCCM/Intune, JAMF, internal repo, artifact registry)
• Notes on required settings (telemetry off, auto-update rules, signed binaries required)

Keep it simple enough to update weekly without drama.

4) Implement technical enforcement (choose controls that match your environment)

Map restrictions to enforcement points:

Endpoints

• Application allowlisting / controlled execution (where feasible)
• Admin rights restriction and just-in-time elevation
• MDM policies to block unapproved app installs
• Browser extension allowlists (often overlooked)

Servers and cloud

• Golden images and hardened baselines
• Only install from approved repos; restrict package managers
• Immutable infrastructure patterns where possible (changes via pipeline, not SSH)

CI/CD and code dependencies

• Approved base images and curated registries
• Dependency allow/deny rules for production builds
• Signed artifacts and provenance where your program supports it

Your objective is consistent: reduce pathways for unreviewed code to execute in controlled environments.

5) Integrate with change management and third-party risk

Tie SA-6 to processes you already run:

• Change management: any new software in production requires a ticket, approval, and implementation evidence
• Third-party onboarding: software publishers/providers become third parties; perform due diligence proportionate to risk (security posture, support lifecycle, vulnerability handling)
• Procurement and licensing: ensure requests are centralized to avoid shadow IT and license noncompliance

6) Implement exception handling that doesn’t turn into a backdoor

Create an exception workflow with minimum fields:

• Requestor, business justification
• Systems/users impacted
• Duration and expiry
• Risk acceptance owner (not the requestor)
• Compensating controls (network segmentation, extra logging, EDR policy, restricted privileges)
• Review outcome and closure evidence

Treat exceptions as time-bound by default. Track them like vulnerabilities: visible queue, owner, and closure criteria.

7) Monitor and test control health

Run control health checks that answer:

• What unapproved software is installed or executed?
• Did the enforcement tool block anything? Was it investigated?
• Are exceptions current, approved, and still justified?
• Are “approved lists” synchronized with packaging tools and access controls?

Daydream fits naturally here as the system of record for control cards, evidence bundles, recurring control health checks, and remediation tracking so you can prove SA-6 is operating without rebuilding your whole stack. ²

Required evidence and artifacts to retain

Retain an evidence bundle that shows design and operation:

Design artifacts

• SA-6 control card (owner, scope, triggers, steps, exceptions) ²
• Software Usage Restrictions policy/standard
• Approved Software Register (current version + change history)
• Exception procedure and risk acceptance authority matrix

Operating evidence

• Endpoint/server/software inventory exports (time-stamped)
• Screenshots/exports of allowlist/denylist configurations
• MDM/endpoint management policies that prevent unauthorized installs
• EDR/app control logs showing blocks or detections tied to unauthorized software
• Change tickets for new software approvals and production deployments
• Exception tickets with approvals and expiry tracking
• Periodic control health check results + remediation closure evidence ²

Common exam/audit questions and hangups

Expect these, and prepare the evidence before you’re asked:

1. “Show me your approved software list. Who approves additions?”
   Hangup: list exists but isn’t used by IT or engineering.

2. “How do you prevent end users from installing unapproved software?”
   Hangup: local admin rights, no MDM enforcement, reliance on policy statements.

3. “How do you detect unauthorized software already present?”
   Hangup: inventory tools exist, but no review workflow or follow-up.

4. “How do you handle exceptions, and who signs risk?”
   Hangup: exceptions approved by the same team requesting them.

5. “How do you control software in cloud workloads and containers?”
   Hangup: endpoint controls exist, but servers and images are unmanaged.

Frequent implementation mistakes (and how to avoid them)

• Mistake: “Approved software” means “anything purchased.”
  Fix: approval is a security and operational decision; procurement is a separate gate.

• Mistake: Allowlist is a spreadsheet that never matches reality.
  Fix: reconcile allowlist to software inventory and packaging sources on a defined cadence.

• Mistake: No controls for browser extensions and plugins.
  Fix: implement extension allowlisting and restrict admin-level add-ons.

• Mistake: Exceptions are permanent.
  Fix: time-box exceptions, require re-approval, and track compensating controls.

• Mistake: Dev and build environments are ignored.
  Fix: apply SA-6 to build runners, base images, and artifact sources so unreviewed dependencies do not ship.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for SA-6, so don’t anchor your program to a specific regulator penalty narrative here. The practical risk is still material: unauthorized software is a common precursor to malware execution, data loss pathways, license disputes, and unplanned operational fragility. SA-6 also affects your ability to answer customer due diligence questions credibly because customers often test whether restrictions are real, not aspirational. ¹

Practical 30/60/90-day execution plan

First 30 days (stand up governance and visibility)

• Name an SA-6 owner and publish the SA-6 control card ²
• Define in-scope asset groups (endpoints, servers, CI/CD runners)
• Produce a first Approved Software Register from existing installed-software inventory
• Turn on or validate software inventory collection (endpoint management/EDR)
• Create the exception workflow in ITSM and require risk-owner approval

Days 31–60 (enforce high-signal restrictions)

• Remove local admin rights where feasible; implement just-in-time elevation for exceptions
• Deploy baseline application control policies for high-risk categories (unsigned executables, user-writable paths)
• Implement browser extension allowlisting in managed browsers
• Require change tickets for production software installs and server package changes
• Start a recurring control health check and remediation tracking ²

Days 61–90 (expand coverage and make it sustainable)

• Extend restrictions to servers, golden images, and container base images
• Integrate third-party intake: new software publishers trigger due diligence and approval steps
• Define metrics you can defend qualitatively in governance meetings (trend of unauthorized software findings, exception backlog)
• Conduct an internal audit-style walkthrough: pick a sample of systems and prove approved/blocked/exception paths end-to-end
• Centralize evidence in a single place (Daydream or your GRC repository) with a minimum evidence bundle definition ²

Frequently Asked Questions

Do we need application allowlisting to satisfy SA-6?

SA-6 expects restrictions that work in practice, and allowlisting is one strong option for certain environments. If you can’t allowlist broadly, implement compensating controls such as removing admin rights, restricting installation sources, and monitoring unauthorized execution with documented follow-up. ¹

How do we handle developer tools that change frequently?

Put developer tooling in the “conditional” category with constraints: approved publishers, approved distribution channels, and role-based assignment to dev endpoints. Control the path into production by restricting build runners, base images, and artifact sources.

What counts as “software” under SA-6 in cloud-native environments?

Treat OS packages, agents, containers/base images, runtime libraries that ship with workloads, and administrative plugins as software in scope. If it can execute in your environment or affect production behavior, it belongs in your restriction model. ¹

How strict should exception expirations be?

Set expirations short enough that you re-validate business need, but long enough that teams will comply instead of bypassing the process. The key audit point is that exceptions have a named approver, compensating controls, and a defined re-approval mechanism.

We have an approved software list, but auditors say it isn’t “operational.” What usually fixes that?

Show enforcement and outcomes: configuration screenshots/exports, block logs, ticketed approvals, and an exception register with closures. Auditors want proof the list drives technical controls and real decisions, not just a document.

Where does Daydream fit if we already have MDM/EDR and ITSM?

Daydream is the control operations layer: control cards, defined evidence bundles, recurring health checks, and remediation tracking to validated closure. It helps you answer audits quickly because the SA-6 story, ownership, cadence, and evidence live in one place. ²

Footnotes

1. NIST SP 800-53 Rev. 5

2. NIST SP 800-53 Rev. 5 OSCAL JSON

3. NIST SP 800-53 Rev. 5; Source: NIST SP 800-53 Rev. 5 OSCAL JSON; Source: NIST SP 800-53 Rev. 5 DOI