PR.PS-05: Installation and execution of unauthorized software are prevented

PR.PS-05 is a requirement-level control statement from NIST Cybersecurity Framework (CSF) 2.0: your program must prevent people and systems from installing or running software you have not approved (NIST CSWP 29). For a CCO or GRC lead, the fastest way to make this real is to treat it as a “deny-by-default” capability with tightly managed exceptions: if software is not explicitly allowed, it should not execute, and users should not be able to install it.

This requirement shows up in real incidents as ransomware execution, “shadow IT” agents on endpoints, unapproved remote access tools, crypto miners on servers, and developer-installed tooling that bypasses logging. Auditors rarely accept “users are told not to install software” as compliance. They look for enforceable controls, clear ownership, and evidence that the controls run continuously and exceptions are governed.

The guidance below breaks PR.PS-05 into implementable steps across endpoints, servers, and cloud workloads, with the artifacts you should retain for assurance and audit readiness. It also calls out common hangups: admins vs. developers, BYOD, ephemeral workloads, and third-party-managed devices.

Regulatory text

Requirement: “Installation and execution of unauthorized software are prevented” (NIST CSWP 29; NIST CSF 1.1 to 2.0 Core Transition Changes).

Operator interpretation: You need controls that (1) stop unauthorized software from being installed and (2) stop unauthorized software from running, even if it lands on a device by other means (for example, copied binaries, portable apps, scripts, or malicious payloads). “Prevented” implies enforceable technical guardrails plus governance for exceptions, not a policy memo.

What an operator must do:

• Establish an authoritative definition of “authorized software” and maintain an inventory or allowlist that reflects that definition.
• Enforce preventive controls across covered assets (endpoints, servers, virtual machines, containers where feasible).
• Detect and respond to attempted violations with tickets, remediation, and exception pathways that are time-bound and approved.

Plain-English interpretation (what PR.PS-05 really demands)

PR.PS-05 is about controlling code execution risk. Software is any executable code path: installers, packaged apps, command-line tools, browser extensions, scripts, macros, drivers, agents, and container images. Unauthorized means “not approved under your process,” not merely “malicious.”

From an exam perspective, the control fails in two common ways:

1. You can’t prove what’s authorized. Teams say “only IT-approved software,” but there is no system of record, no approval workflow, and no baseline list.
2. You can’t prove prevention. You detect after-the-fact via EDR, but users can still install and run anything.

Who it applies to (entity and operational context)

PR.PS-05 applies to any organization operating a cybersecurity program under NIST CSF 2.0 (NIST CSWP 29). In practice, scope it by asset class and risk:

In-scope assets (typical):

• Corporate endpoints (Windows/macOS/Linux)
• Production and non-production servers (including jump hosts)
• Privileged admin workstations
• VDI and shared workstations
• Cloud VMs and managed endpoints
• Build agents and CI runners (often missed)

Operational contexts that drive design choices:

• Highly regulated workloads: Favor strict allowlisting and locked-down execution paths.
• Developer-heavy environments: Allowlisting can work, but requires sane exception workflows and separation between dev sandboxes and enterprise endpoints.
• Third-party-managed devices: You still need contractual and technical mechanisms (MDM/EDR visibility, configuration requirements, and attestation) if those devices access your data or networks.

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

1) Define “authorized software” and set ownership

Create a short standard that answers:

• What counts as software (apps, scripts, extensions, container images)?
• What approval looks like (security review required for certain categories)?
• Who can approve (IT, Security, app owner), and who is accountable for the list?

Deliverable: a one-page “Authorized Software Standard” mapped to PR.PS-05 (NIST CSWP 29).

2) Establish the system of record for authorization

Pick one authoritative place for approval decisions and baselines:

• ITSM catalog entries for standard apps
• Endpoint management “approved apps” list
• Container registry allowlist for images
• Code signing trust list for internal apps

Control test: Can you produce the approved list on request, with date and approver?

3) Prevent installation via least privilege and device controls

Installation prevention typically comes from:

• Removing local admin rights for standard users
• Privileged access workflows for admin tasks
• Device management policies that block unknown installers and package managers where appropriate

Common hangup: “Developers need admin.” Solve with segmented dev environments, just-in-time admin, or dedicated build boxes, not broad exemptions.

4) Prevent execution with application control / allowlisting (where feasible)

Execution prevention is the differentiator. Depending on platform maturity:

• Use application control to allow only signed/approved executables
• Block execution from high-risk paths (user profile temp directories, downloads) where strict allowlisting is not possible
• Control script interpreters and macro execution paths

Practical approach: Start with high-risk populations (privileged workstations, servers) and expand as you harden.

5) Cover “non-traditional software” paths

Attackers and power users avoid installers. Address:

• Portable executables (run-from-USB or user profile)
• PowerShell, Python, Node runtimes
• Browser extensions
• Unsanctioned remote access tools
• Container image pulls from public registries

Decision point: If you can’t block, then constrain and monitor with clear compensating controls and approvals.

6) Build an exception process that auditors can live with

You will have exceptions. Make them:

• Documented with business justification
• Risk-reviewed (Security)
• Time-bound with expiry
• Logged in a trackable system (ticketing)
• Periodically revalidated

Evidence expectation: exception register + sample approvals + proof expirations are enforced.

7) Instrument monitoring and response for attempted violations

Prevention controls still generate events:

• Blocked execution attempts
• Unauthorized install attempts
• New software discovery on endpoints/servers

Operationalize response:

• Triage playbook (what constitutes an incident vs. a user request)
• Auto-ticketing with required fields (asset, user, hash/path, control that blocked, remediation step)
• Metrics for internal management (trend, top blocked apps), without making numeric claims in your policy text

8) Prove it works (continuous evidence)

Auditors will ask for proof across time, not a screenshot once. Set a recurring evidence pull:

• Monthly configuration exports
• Sampling of blocked events and closure tickets
• Quarterly allowlist review sign-off

If you use Daydream to manage control ownership and recurring evidence collection, map PR.PS-05 to a control owner, define your evidence checklist, and schedule collection reminders so you can answer “show me” requests without scrambling.

Required evidence and artifacts to retain

Keep artifacts that prove design + operating effectiveness:

Governance

• Authorized Software Standard and policy mapping to PR.PS-05 (NIST CSWP 29)
• RACI/ownership for approvals and platform enforcement
• Exception procedure and exception register export

Technical configurations (by platform)

• Application control / allowlisting policies (exported configs)
• Endpoint management policies preventing local admin and controlling installs
• Server hardening standards showing execution restrictions
• Container registry policies and approved image list (if applicable)

Operational evidence

• Sample of blocked execution/install events with associated tickets and remediation
• Software inventory reports showing discovery and remediation of unauthorized items
• Periodic review records: allowlist change log, approvals, and revalidation sign-offs

Change management

• Records of policy updates, rollout plans, and approved exceptions during migration phases

Common exam/audit questions and hangups

• “Show me your authorized software list. Who approved it?” If you can’t name the system of record, you will lose time.
• “How do you prevent execution, not just detect it?” EDR alerts alone usually read as detective, not preventive.
• “Do developers have exemptions? Prove governance.” Auditors expect a controlled exception path, not informal approvals in chat.
• “How do you handle SaaS agents, browser extensions, and scripts?” These frequently slip outside “software” definitions.
• “What about third-party devices?” Expect questions on contractor laptops, MSP admin workstations, and vendor remote tools.

Frequent implementation mistakes (and how to avoid them)

1. Policy-only controls. Fix: implement technical enforcement for both install and execution and keep exported configs as evidence.
2. No clear “authorized” definition. Fix: write an approval standard and maintain a single system of record.
3. Allowlisting without an exception path. Fix: time-bound exceptions with risk review, or teams will bypass controls.
4. Ignoring servers and admin workstations. Fix: prioritize high-impact assets first; these are common execution targets.
5. Over-scoping too early. Fix: phase rollout by risk tiers; document the plan and interim controls.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions. Practically, failure modes are well understood: unauthorized software expands attack surface, enables persistence (unapproved agents), and creates unlogged access paths (remote tools). Treat PR.PS-05 as a foundational control that supports incident prevention and reduces the blast radius of phishing and endpoint compromise.

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and governance)

• Name the PR.PS-05 control owner and write the Authorized Software Standard mapped to PR.PS-05 (NIST CSWP 29).
• Decide the system of record for approved software and define the approval workflow.
• Identify in-scope asset groups: endpoints, servers, privileged workstations, and third-party managed endpoints with access.
• Pull a current software inventory snapshot to understand what “unauthorized” likely means in your environment.

Days 31–60 (implement prevention where it counts most)

• Remove local admin from standard users where feasible; implement privileged workflows for installs.
• Deploy execution controls to a high-risk pilot group (privileged workstations and a server subset).
• Stand up exception handling with expiry and ticketing.
• Define and test alert-to-ticket flow for blocked executions/installs.

Days 61–90 (scale, prove, and audit-harden)

• Expand enforcement to broader endpoint populations based on pilot results.
• Cover non-traditional software: scripts, extensions, portable apps, container images.
• Start recurring evidence collection: configs, event samples, exceptions, and review sign-offs.
• Run an internal audit tabletop: pick a sample device, prove it blocks unauthorized execution, and show the ticket trail.

Frequently Asked Questions

Does PR.PS-05 require strict allowlisting everywhere?

PR.PS-05 requires prevention of unauthorized installation and execution (NIST CSWP 29). Strict allowlisting is the cleanest approach for high-risk assets, but you can phase it and use scoped execution restrictions plus governed exceptions where full allowlisting is not yet workable.

What counts as “unauthorized” if we don’t have a formal approved software list yet?

Until you define authorized software, you cannot consistently define unauthorized. Start by creating a system of record (catalog or allowlist), then treat everything outside it as unauthorized unless it goes through exception approval.

How do we handle developers who need tooling that changes frequently?

Segment dev work into managed dev environments (VDI, dev boxes, or sandboxes) and keep corporate endpoints tighter. Use a rapid exception workflow with expiry for new tools, and require approved sources (signed packages, approved registries).

Is EDR enough to meet the “prevented” language?

EDR can support PR.PS-05, but auditors often read EDR-only as detection and response. Pair EDR with enforceable controls: least privilege for installation and application control or execution restrictions for running code.

How do we apply PR.PS-05 to third-party access and tools?

If third parties can access your network or data, control the software they run in that context through contractual requirements, enforced access methods (managed VDI/jump hosts), and monitoring. Document exceptions for third-party tools like remote support agents.

What evidence should we produce first if an auditor asks tomorrow?

Produce the Authorized Software Standard mapped to PR.PS-05 (NIST CSWP 29), your current approved software list or catalog export, and configuration exports showing prevention controls are deployed. Add a small sample of blocked events tied to tickets to demonstrate operation.