Protect is the largest share of most security budgets, yet CSF 2.0 assessments often score it from tool deployment counts rather than from whether its 22 outcomes are actually achieved. CSF 2.0 rebuilt Protect from version 1.1: access control became PR.AA, three Categories (PR.IP, PR.MA and PR.PT) were withdrawn, and two new ones, Platform Security (PR.PS) and Technology Infrastructure Resilience (PR.IR), took their outcomes. This guide works through the five Protect Categories at Subcategory level with NIST's Implementation Examples, what changed from 1.1, the evidence an assessor should expect, metrics, the non-human identity angle and framework mappings. It is for security architects, control owners, GRC teams and auditors who know the CSF basics; for the framework as a whole see the NIST CSF 2.0 Guide.
Key takeaways
- Protect has five Categories and 22 Subcategories: PR.AA (6), PR.AT (2), PR.DS (4), PR.PS (6) and PR.IR (4).
- Services are named identities. PR.AA-01 covers identities and credentials for "authorized users, services, and hardware", and PR.AA-03 requires users, services and hardware to be authenticated, so service accounts, API keys and workload identities are in scope by wording, not interpretation.
- Logging is a Protect outcome. PR.PS-04 requires log records to be generated and made available for continuous monitoring; Detect consumes them, but Protect is where their absence is scored.
- Backups sit in Protect, integrity checks in Recover. PR.DS-11 requires backups to be created, protected, maintained and tested; RC.RP-03 requires their integrity to be verified before restoration.
- Old 1.1 scores do not carry over cleanly. Thirty-five 1.1 Protect Subcategories were withdrawn and spread across PR.PS, PR.IR, PR.AA, ID.AM, ID.RA, ID.IM and GV.RR, so a relabelled 1.1 assessment misstates coverage.
What Protect covers
CSF 2.0 (NIST CSWP 29, 26 February 2024) describes Protect as "Safeguards to manage the organization's cybersecurity risks are used." The CSWP's expanded text says that once assets and risks are identified and prioritised, Protect "supports the ability to secure those assets" to prevent or lower the likelihood and impact of adverse events, and lists the five outcome areas below. In NIST SP 800-61 Revision 3 (April 2025), Protect sits with Govern and Identify as preparation for incident response, which is why several Protect outcomes (logging, backups, role-based training) are tested hardest during incidents.
CSF describes outcomes, not controls. The Implementation Examples are, in NIST's words, "notional examples of concise, action-oriented steps" and "not a comprehensive list". Use them to understand intent; use SP 800-53, ISO/IEC 27001 or CIS Controls for the controls that achieve each outcome.
The five Categories and 22 outcomes
PR.AA Identity Management, Authentication, and Access Control
| Subcategory | Outcome | NIST Implementation Examples (summarised) |
|---|---|---|
| PR.AA-01 | Identities and credentials for authorized users, services, and hardware are managed by the organization | Track and fulfil access requests with owner permission; issue, manage and revoke certificates, tokens, keys and other credentials; unique device identifiers; label hardware |
| PR.AA-02 | Identities are proofed and bound to credentials based on the context of interactions | Verify identity at enrolment with government-issued credentials; a different credential for each person, no sharing |
| PR.AA-03 | Users, services, and hardware are authenticated | Require MFA; minimum authenticator strength; periodic reauthentication based on risk; emergency access to safety-critical accounts |
| PR.AA-04 | Identity assertions are protected, conveyed, and verified | Protect SSO and federation assertions; standards-based generation, signing, encryption and signature validation |
| PR.AA-05 | Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties | Periodic and change-triggered access reviews; attribute-based decisions (location, time, endpoint health); minimum necessary access; separation of duties reviews |
| PR.AA-06 | Physical access to assets is managed, monitored, and enforced commensurate with risk | Guards, cameras, locks and alarms; extra controls for high-risk areas; escort visitors |
PR.AT, PR.DS, PR.PS and PR.IR
| Subcategory | Outcome | NIST Implementation Examples (summarised) |
|---|---|---|
| PR.AT-01 | Personnel are provided with awareness and training for general tasks | Basic awareness for all users including suppliers; social engineering recognition and reporting; consequences of violations; testing; annual refreshers |
| PR.AT-02 | Individuals in specialized roles are provided with awareness and training | Identify specialised roles (security, finance, senior leadership, anyone with critical data access); role-based training; testing; annual refreshers |
| PR.DS-01 | The confidentiality, integrity, and availability of data-at-rest are protected | Encryption, signatures and hashes for stored data and images; full disk encryption on endpoints; validate software signatures; restrict removable media |
| PR.DS-02 | The confidentiality, integrity, and availability of data-in-transit are protected | Encrypt and sign network communications; encrypt or block outbound sensitive email; block personal file sharing; no production data in non-production |
| PR.DS-10 | The confidentiality, integrity, and availability of data-in-use are protected | Remove confidential data from memory when no longer needed; isolate data in use from other users and processes |
| PR.DS-11 | Backups of data are created, protected, maintained, and tested | Near-real-time backup of critical data; test restores at least annually for all data source types; some backups offline and offsite; geographic separation |
| PR.PS-01 | Configuration management practices are established and applied | Hardened baselines with least functionality; review defaults on install or upgrade; monitor for baseline deviation |
| PR.PS-02 | Software is maintained, replaced, and removed commensurate with risk | Routine and emergency patching to plan timeframes; replace containers rather than update; replace end-of-life software; remove unauthorised and unnecessary software |
| PR.PS-03 | Hardware is maintained, replaced, and removed commensurate with risk | Replace hardware lacking security capability; end-of-life plans; secure, auditable disposal |
| PR.PS-04 | Log records are generated and made available for continuous monitoring | All systems and cloud services generate logs; share securely with logging infrastructure; record data needed by zero trust architectures |
| PR.PS-05 | Installation and execution of unauthorized software are prevented | Allowlisting or denylisting where risk warrants; verify source and integrity before install; approved DNS with malicious-domain blocking; approved software only |
| PR.PS-06 | Secure software development practices are integrated, and their performance is monitored throughout the software development life cycle | Protect code from tampering; minimise vulnerabilities in releases; maintain and securely dispose of production software |
| PR.IR-01 | Networks and environments are protected from unauthorized logical access and usage | Segment by trust boundary and platform type (IT, IoT, OT, mobile, guest); restrict external traffic; zero trust; check endpoint health before access |
| PR.IR-02 | The organization's technology assets are protected from environmental threats | Protection from flood, fire, wind, heat and humidity; include this in service provider requirements |
| PR.IR-03 | Mechanisms are implemented to achieve resilience requirements in normal and adverse situations | Avoid single points of failure; load balancing; redundant storage and power |
| PR.IR-04 | Adequate resource capacity to ensure availability is maintained | Monitor storage, power, compute and bandwidth; forecast and scale |
What changed from CSF 1.1
The CSF 2.0 catalogue records where each withdrawn 1.1 outcome went. The moves that most affect an assessment:
| CSF 1.1 | CSF 2.0 destination | Why it matters |
|---|---|---|
| PR.AC-01 to PR.AC-07 (Access Control) | PR.AA-01 to PR.AA-06, with PR.AC-03 and PR.AC-05 network parts in PR.IR-01 | Network segmentation and remote access are now judged as infrastructure resilience |
| PR.IP-01, PR.IP-03 baselines and change control | PR.PS-01, ID.RA-07 | Change and exception tracking is a risk assessment outcome |
| PR.IP-04 backups | PR.DS-11 | Backups became a data security outcome |
| PR.IP-07 to PR.IP-10 improvement, plans and testing | ID.IM-02 to ID.IM-04 | Response and recovery plans and their tests are assessed in Identify |
| PR.IP-11 HR practices | GV.RR-04 | Screening and leaver processes are a governance outcome |
| PR.IP-12 vulnerability management plan | ID.RA-01, PR.PS-02 | Finding vulnerabilities is Identify; patching is Protect |
| PR.PT-01 audit logs | PR.PS-04 | Log generation stays in Protect |
| PR.PT-05 resilience mechanisms; PR.DS-04 capacity | PR.IR-03; PR.IR-04 | Availability engineering is explicit |
| PR.MA-01, PR.MA-02 maintenance | ID.AM-08, PR.PS-02, PR.PS-03 | Maintenance is part of asset life cycle and platform security |
| PR.AT-03 to PR.AT-05 third parties, executives, security staff | PR.AT-01, PR.AT-02 | Two outcomes now cover all audiences |
Implementing Protect
- Start from the Target Profile: not every Protect outcome needs the same rigour. Use Govern's risk tolerance (GV.RM-02) to decide which Subcategories are priority, and record the rationale. See the CSF 2.0 Organisational Profiles Template.
- Assess each Subcategory against its scope: PR.AA-01 for workforce, customers, services and devices separately; PR.PS-04 per platform including SaaS; PR.DS-11 per data source type. A single score hides gaps.
- Close identity gaps first: PR.AA outcomes are prerequisites for most others. Phishing-resistant MFA for administrators, a credential inventory for services, and access reviews that include machine identities usually give the largest risk reduction. See the NIST SP 800-63B-4 Authenticator Assurance Levels Guide.
- Baseline and monitor configuration (PR.PS-01): adopt hardened baselines, deploy in audit mode, then enforce. See the Configuration Drift and Baseline Enforcement Guide.
- Restrict software (PR.PS-05): roll out allowlisting in audit mode to a pilot ring, review blocks, then enforce in rings, keeping a documented rollback to audit mode. See the Application Allowlisting Guide.
- Prove backups (PR.DS-11): test restores for every data source type at least annually, as the Implementation Example states, and keep some copies offline. See the Backup Security and Immutable Backup Guide.
- Segment and verify endpoints (PR.IR-01): segment by trust boundary and platform type, and gate production access on endpoint health. See the Network Segmentation Guide.
- Re-profile: update the Current Profile at Subcategory level and feed gaps into the action plan.
Small versus large organisations: a small organisation can meet much of Protect through platform defaults it already pays for: MFA and conditional access in its identity provider, device encryption, managed updates, built-in SaaS logging and a backup service with tested restores. NIST's Small Business Quick-Start Guide (SP 1300) is written for this case. Large organisations need Subcategory-level ownership (often a different team per Category), central log collection across hundreds of platforms, formal secure development practice under PR.PS-06, and resilience engineering under PR.IR-03 tied to recovery objectives.
Evidence and assessment
| Subcategory | Weak evidence | Strong evidence |
|---|---|---|
| PR.AA-01 | IAM tool deployed | Inventory of human and non-human identities with owners, credential types and expiry |
| PR.AA-03 | MFA policy | MFA coverage report by population, including exclusions and service authentication method |
| PR.AA-05 | Access review schedule | Completed reviews with revocations, and leaver revocation times |
| PR.AT-02 | Training platform licence | List of specialised roles with completion and test results |
| PR.DS-01, PR.DS-02 | Encryption standard | Encryption coverage by data store and protocol, with key management records |
| PR.DS-11 | Backup job success rate | Restore test records per data source type, with offline copy verified |
| PR.PS-01 | Baseline document | Compliance scan results against the baseline and deviation tickets |
| PR.PS-02 | Patch policy | Patch latency against plan timeframes, and end-of-life inventory |
| PR.PS-04 | SIEM licence | Log source coverage list per platform, including SaaS and cloud services |
| PR.IR-01 | Network diagram | Segmentation rules tested, and endpoint health checks enforced at access |
Metrics that show Protect is working
- Phishing-resistant MFA coverage: share of privileged accounts using it (PR.AA-03).
- Non-human credential age: share of service credentials older than the policy maximum (PR.AA-01).
- Baseline compliance: share of assets meeting the hardened baseline (PR.PS-01).
- Patch latency: share of critical patches applied within the plan timeframe (PR.PS-02).
- Log source coverage: share of in-scope platforms sending logs centrally (PR.PS-04).
- Restore success: share of data source types with a successful restore test in the last 12 months (PR.DS-11).
Identity and NHI in Protect
PR.AA is the only CSF Category that names services next to users and hardware, which makes it the anchor for non-human identity controls in a CSF programme.
- PR.AA-01 credential management: NIST's example "Issue, manage, and revoke cryptographic certificates and identity tokens, cryptographic keys ... and other credentials" is a machine identity life cycle outcome. The Okta Support System Breach began with a service account credential saved in a personal Google profile, exactly the kind of credential an inventory with owners should catch.
- PR.AA-03 authentication of services: prefer short-lived tokens, workload identity federation and certificates over static secrets.
- PR.AA-05 least privilege: include service accounts, OAuth grants and AI agents in access reviews. See the Least Privilege Techniques Guide.
- PR.DS-01 key protection: encryption at rest fails if the keys sit beside the data. In the LastPass Breach 2022, stolen DevOps secrets gave access to encrypted cloud backups.
- PR.PS-04 logging: service and API activity must be logged with enough detail to tell one machine identity from another. See the Non-Human Identity (NHI) Guide.
Mapping to other frameworks
NIST lists a CSF 2.0 to SP 800-53 Rev 5 mapping, a CIS Controls v8.1 mapping and an ISO/IEC 27001:2022 mapping among the CSF 2.0 Informative References; use those for formal crosswalks. The table orients by control purpose.
| Protect Category | SP 800-53 Rev 5 (related) | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 |
|---|---|---|---|
| PR.AA | AC-2, AC-3, AC-5, AC-6, IA-2, IA-4, IA-5, IA-8, IA-12, PE-3, PE-6 | 5.15 to 5.18, 7.2, 8.2, 8.5 | Controls 5 and 6 |
| PR.AT | AT-2, AT-3 | 6.3 | Control 14 |
| PR.DS | SC-8, SC-12, SC-13, SC-28, MP-7, CP-9 | 8.11, 8.12, 8.13, 8.24 | Controls 3 and 11 |
| PR.PS | CM-2, CM-6, CM-7, CM-10, CM-11, SI-2, AU-2, AU-12, SA-8, SA-15, SA-22 | 8.8, 8.9, 8.15, 8.19, 8.25 to 8.28 | Controls 2, 4, 7, 8 and 16 |
| PR.IR | SC-5, SC-6, SC-7, CP-11, PE-13, PE-14 | 7.5, 8.6, 8.14, 8.20, 8.22 | Controls 12 and 13 |
For control-level detail see the NIST SP 800-53 AC Access Control and NIST SP 800-53 IA Identification and Authentication guides, and the NIST CSF to ISO 27001 Mapping Guide.
Common pitfalls
- Scoring by deployment: "EDR on 95% of endpoints" says nothing about PR.PS-05 or PR.AA-05. Score outcomes against their full scope.
- Humans only in PR.AA: access reviews and MFA reports cover the workforce while service accounts, API keys and integrations are left out, despite the outcome naming services.
- Backups never restored: job success rates reported for PR.DS-11 while restore tests are missing for whole data source types such as SaaS or configuration.
- Logs generated but not available: PR.PS-04 requires logs to reach monitoring; local-only logs and SaaS audit logs left at native retention fail it.
- 1.1 relabelling: PR.IP scores carried into PR.PS without noticing that plans, testing and HR practice moved to Identify and Govern.
- Allowlisting stuck in audit mode: PR.PS-05 is reported as met because the policy exists, though it never moved to enforcement.
Practitioner checklist
- Assess all 22 Protect Subcategories individually, scoped to every population and platform.
- Include services and devices, not only people, in PR.AA inventories, MFA coverage and access reviews.
- Name the specialised roles that need PR.AT-02 training and record completion.
- Test restores for each data source type at least annually and keep an offline copy.
- Maintain hardened baselines and measure compliance and deviation.
- Track patch latency against the vulnerability management plan's timeframes.
- List log sources per platform and confirm each reaches central monitoring.
- Segment by trust boundary and enforce endpoint health checks for production access.
- Re-map any CSF 1.1 Protect assessment using the withdrawn-outcome destinations.
Standards and references
- NIST: The NIST Cybersecurity Framework (CSF) 2.0, CSWP 29
- NIST: Cybersecurity Framework
- NIST: CSF 2.0 Informative References
- NIST: SP 800-53 Rev. 5
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST: SP 1300 CSF 2.0 Small Business Quick-Start Guide
Related NHI Mgmt Group resources: NIST CSF 2.0 Guide · NIST CSF 2.0 Govern Function Guide · NIST CSF 2.0 Identify Function · NIST CSF 2.0 Detect Function · NIST SP 800-53 Guide