SA-6: Software Usage Restrictions

SA-6: software usage restrictions requirement means you must define, communicate, and technically enforce what software can and cannot be installed, executed, or used in your environment, and keep evidence that the restrictions operate in practice. Operationalize it by setting approved-use rules, enforcing them with allow/deny controls, and producing repeatable audit artifacts tied to an owner and procedure. ¹

Key takeaways:

• Write explicit software usage rules (allowed, prohibited, conditional) and assign a control owner. ¹
• Back policy with technical enforcement (application allowlisting/denylisting, device management, least privilege) and logs you can produce on demand. ¹
• Maintain assessment-ready evidence: inventory, exceptions, approvals, and test results that show restrictions work. ¹

SA-6 sits in the NIST SP 800-53 System and Services Acquisition (SA) family and addresses a recurring control failure pattern: organizations state “only approved software is allowed,” but cannot prove consistent enforcement across endpoints, servers, and cloud workloads. Auditors and authorizing officials expect you to translate “software usage restrictions” into operational rules that are both understandable to users and enforceable by IT.

This requirement matters most where unmanaged software can create security, licensing, privacy, and supply chain risk. Examples include: engineers installing unsigned tools on build servers, business users running unapproved browser extensions that exfiltrate data, or administrators deploying freeware utilities with unclear provenance onto privileged systems. SA-6 is also a common dependency control for vulnerability management and incident response because you cannot reliably patch, monitor, or investigate what you do not control.

This page gives you requirement-level implementation guidance: what SA-6 expects, who it applies to, the quickest way to implement enforcement, what evidence to retain, and the audit questions that typically stall teams. Primary reference is the NIST SP 800-53 Rev. 5 control catalog. ¹

Plain-English interpretation (what SA-6 is asking for)

SA-6: software usage restrictions requirement expects you to:

1. set clear restrictions on software use (what is permitted, what is forbidden, and under what conditions), and
2. put those restrictions into practice through process and technical controls, and
3. keep proof you do this consistently.

In operator terms: “approved software only” is not enough unless you can show how software becomes approved, how you block unapproved software, how you handle exceptions, and what telemetry proves enforcement.

NIST publishes the authoritative control wording and context in SP 800-53 Rev. 5. ¹

Regulatory text

Excerpt (as provided): “NIST SP 800-53 control SA-6.” ²

Operator meaning: You must implement SA-6 in a way that is assessable. That usually requires (a) a documented rule set for software usage and (b) mechanisms that restrict execution/installation consistent with that rule set, supported by durable evidence. Your goal is that an assessor can trace: requirement → policy/standard → configuration/enforcement → logs/reports → exceptions → periodic review. ¹

Who it applies to (entity and operational context)

SA-6 applies wherever you have adopted NIST SP 800-53 as a control baseline, commonly:

• Federal information systems and programs assessed against NIST SP 800-53. ¹
• Contractor systems handling federal data where NIST SP 800-53 controls are flowed down contractually or used to support authorization. ¹

Operationally, it applies across:

• Managed endpoints (Windows/macOS/Linux)
• Servers (on-prem and cloud IaaS)
• Container hosts and images
• SaaS environments where “software” manifests as integrations, plug-ins, add-ons, extensions, scripts, and marketplace apps
• Privileged admin tooling, remote access tools, and automation frameworks

If you only implement controls on laptops and ignore build systems, jump boxes, and SaaS add-ons, you will struggle to defend SA-6 during assessment.

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

1) Assign ownership and define scope

• Name a control owner (often endpoint engineering, security engineering, or IT operations).
• Define in-scope environments (endpoints, servers, cloud workloads, and key SaaS tenants).
• Document software categories you will govern: installers, portable executables, scripts, browser extensions, SaaS apps/integrations, container images.

Deliverable: SA-6 control record with owner, scope, and system coverage statement.
Practical note: this is where tools like Daydream help, because mapping SA-6 to an owner, procedure, and recurring evidence artifacts prevents “policy-only compliance.” ¹

2) Define your restriction model (allow, deny, conditional)

Create a “software usage restrictions standard” that answers:

• Allowed by default: corporate-managed apps from your approved catalog; OS-native tools; signed, vendor-supported software.
• Explicitly prohibited: pirated software; end-of-life software; tools that bypass security controls; unauthorized remote admin tools.
• Conditional allowed: developer tooling, pen-test tools, or open-source packages allowed only on specific devices, networks, or roles; time-bound approvals.

Use a table so the rules are assessable:

Software type	Default rule	Approval path	Enforcement method	Evidence source
Endpoint apps	Allow only approved	Service request + security review	Device management + allow/deny	MDM report + approval ticket
Browser extensions	Deny except approved	Security review	Browser policy	Browser extension inventory export
Server utilities	Allow only from approved repo	Change management	Least privilege + app control	Change record + host config report
SaaS integrations	Deny unless approved	AppSec + data owner	SaaS admin controls	SaaS audit log + approved integration list

Deliverable: Approved/prohibited/conditional list (or criteria), plus the procedure for requesting exceptions.

3) Implement technical enforcement (don’t stop at policy)

Pick enforcement points that match your architecture:

• Endpoints: application control (allowlisting/denylisting), managed app catalogs, installation restrictions, and standard user privileges.
• Servers: configuration management to prevent ad hoc installs; restrict admin access; block execution from user-writable directories where feasible.
• SaaS: tenant-level controls for marketplace apps, OAuth app restrictions, and extension policies.
• Cloud/container: approved base images, image signing/attestation where available, and CI/CD gating to block unapproved packages.

Your objective is simple: if a user tries to run unapproved software, it fails or generates an actionable alert.

Deliverable: Configuration baselines and exported settings that show restrictions are enabled.

4) Build an exception process that auditors can follow

Most environments need exceptions. Make them controlled:

• Require a business justification and data sensitivity context.
• Require security review for high-risk categories (remote access tools, unsigned binaries, packet capture tools).
• Set time bounds and renewal requirements.
• Record compensating controls (segmentation, monitoring, limited accounts).

Deliverable: Exception register with approver, rationale, scope (device/user/system), and expiration.

5) Prove operations: monitoring, testing, and periodic review

• Run periodic reporting from enforcement tools: blocked executions, unauthorized installs attempted, out-of-policy extensions detected.
• Perform spot checks on representative systems (endpoints, servers, privileged admin workstations).
• Review the approved software list and exception register on a defined cadence and upon major changes (new OS version, new EDR/MDM, merger, new SaaS platform).

Deliverable: Recurring evidence pack (reports + review minutes/attestation).

Required evidence and artifacts to retain (assessment-ready)

Maintain artifacts that show design and operating effectiveness:

• Policy/standard: software usage restrictions standard; acceptable use tie-in; SaaS integration standard if applicable. ¹
• Approved software catalog: list or criteria; ownership; last review date.
• Technical configuration exports: MDM/app control settings, server hardening baselines, SaaS marketplace restriction settings.
• Software inventory outputs: endpoint inventory exports, server package lists, SaaS add-on lists (snapshots with timestamps).
• Exception register: approvals, time bounds, compensating controls, closure evidence.
• Testing evidence: sample-based test scripts/results, screenshots/exports showing a block event, or detection workflow.
• Training/communications: user-facing guidance on requesting new software and prohibited categories.

Daydream (or any GRC system) is most helpful here if it can schedule evidence collection and tie each artifact to SA-6 with an owner and recurring due dates. The gap called out most often is missing implementation evidence, not missing policy language. ²

Common exam/audit questions and hangups

Expect these questions in control testing:

1. “Show me how you prevent unapproved software from running.” Bring enforcement configurations and a recent report of blocked attempts.
2. “How does software become approved?” Show workflow, approvers, and risk review criteria.
3. “Do these restrictions apply to servers and cloud workloads too?” Many teams can’t evidence non-endpoint coverage.
4. “How do you govern SaaS add-ons and OAuth apps?” Auditors often treat those as “software” in practice.
5. “How are exceptions controlled, tracked, and retired?” Provide the exception register and an example of expiration/closure.

Hangup to anticipate: teams produce an inventory but cannot show it drives enforcement (or vice versa). SA-6 testing often fails in that seam.

Frequent implementation mistakes (and how to avoid them)

• Mistake: “Approved software only” with no approval mechanism.
  Fix: define a ticketed intake path with required fields (publisher, license, security review outcome, data access).
• Mistake: Enforcement only on laptops.
  Fix: publish scope, then implement compensating controls for servers/CI (restricted admin rights, repo-based installs, immutable images).
• Mistake: Exceptions without expiry.
  Fix: require expiration and renewal; report on expired exceptions monthly.
• Mistake: No proof of operation.
  Fix: save recurring exports (blocked events, policy compliance reports) and document your review actions.
• Mistake: Treating browser extensions and SaaS apps as “out of scope.”
  Fix: explicitly classify them as governed software and apply tenant restrictions where the platform supports it.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list specific cases.

Risk-wise, SA-6 failures usually show up as:

• increased malware/ransomware exposure through unmanaged executables,
• data exposure via unsanctioned plugins/integrations,
• licensing and contractual noncompliance,
• incident response blind spots (unknown tools and persistence mechanisms).

For federal programs and contractors, inability to evidence SA-6 can become an authorization risk because assessors cannot validate control operation against the NIST SP 800-53 baseline. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Assign SA-6 owner and publish scope across endpoints, servers, cloud, and key SaaS tenants. ¹
• Draft the restriction model (allowed/denied/conditional) and define the approval + exception workflows.
• Identify current enforcement tooling coverage (MDM, EDR, application control, SaaS admin controls) and gaps.
• Start collecting baseline evidence: current software inventory exports and current SaaS add-on lists.

Days 31–60 (enforce on the highest-risk surfaces)

• Implement or tighten application execution controls on managed endpoints (start with high-risk categories and admin tools).
• Lock down browser extensions in standard browsers; require approval for exceptions.
• Establish server install restrictions through privileged access + change management and, where possible, standard package repositories.
• Stand up the exception register with expirations and compensating controls.

Days 61–90 (prove repeatability and get assessment-ready)

• Run a control test: attempt to install/run an unapproved app in a controlled way and capture the block/alert evidence.
• Operationalize recurring reporting: blocked events, policy compliance, exception renewals.
• Conduct a documented review meeting (or written attestation) that covers: approved catalog changes, exceptions, and enforcement drift.
• In Daydream, map SA-6 to the owner, procedures, and the exact recurring evidence artifacts you will keep so you can answer assessor requests quickly. ²

Frequently Asked Questions

Does SA-6 require application allowlisting?

NIST SP 800-53 does not prescribe a single technology in the excerpt provided, but assessors will expect restrictions that are enforceable and testable. In practice, allowlisting/denylisting, managed catalogs, and SaaS tenant controls are common ways to demonstrate operation. ¹

Are SaaS marketplace apps and OAuth integrations “software” for SA-6?

Treat them as in scope when they execute code, add functionality, or access data through your tenant. You should restrict which integrations can be installed and keep an approved list plus audit logs or admin exports as evidence. ¹

What evidence is most persuasive to an auditor for SA-6?

Configuration exports that show restrictions are enabled, a current approved software list, and time-stamped reports showing enforcement outcomes (blocked runs, prevented installs, or detected unauthorized items). Pair that with an exception register that shows approvals and expiration. ¹

How do we handle developers who need lots of tools quickly?

Create a “developer-approved” subset with clear boundaries (device class, role eligibility, signing/publisher requirements) and a fast approval path for additions. Keep exceptions for truly uncommon tools and require time bounds plus compensating controls. ¹

We can inventory software, but we can’t block it everywhere. Can we still pass SA-6?

If you cannot block in some areas, document scope limits and implement compensating controls you can evidence (restricted admin access, controlled repositories, CI/CD gates, monitoring with response). Auditors will focus on whether the restriction intent is implemented and demonstrably operating across your defined scope. ¹

What’s the cleanest way to keep SA-6 evidence current?

Put SA-6 on an evidence calendar: periodic configuration exports, inventory snapshots, and exception register reviews saved to a controlled repository. Daydream is a practical fit when you want the owner, procedure, and recurring artifacts tracked in one place with audit-ready retrieval. ²

Footnotes

1. NIST SP 800-53 Rev. 5

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