NIST Cybersecurity Framework 2.0: Protect

Quick answer

The PROTECT Function applies safeguards to reduce the likelihood and impact of cybersecurity events. In NIST CSF 2.0, it contains five Categories: Identity Management, Authentication, and Access Control (PR.AA); Awareness and Training (PR.AT); Data Security (PR.DS); Platform Security (PR.PS); and Technology Infrastructure Resilience (PR.IR). PROTECT turns the priorities established under GOVERN and IDENTIFY into working controls across people, data, systems, and infrastructure.

Who should read this

This guide is for CISOs, IT and security leaders, identity teams, application owners, infrastructure teams, risk professionals, and executives who need to understand what effective protection looks like after an organization has identified its most important assets and risks.

In this guide

What PROTECT means Identity and Access Training Data Security Platform Security Resilience 2026 update Checklist FAQs

What is the PROTECT Function?

PROTECT is the third of the six Functions in the NIST Cybersecurity Framework 2.0. It follows IDENTIFY, where the organization develops an accurate view of its assets, data, suppliers, vulnerabilities, threats, and business risk.

Once an organization understands what matters and how it could be harmed, PROTECT asks a practical question: Which safeguards will reduce the likelihood or impact of that harm? The answer includes technology, but it also includes people, processes, architecture, physical protection, and the ability to continue operating when preventive controls do not work perfectly.

PROTECT is therefore not a shopping list of security products. A control is useful only when it addresses a defined risk, operates consistently, has an accountable owner, produces evidence, and can adapt as the business and threat environment change.

The five Categories of PROTECT

PR.AA

Identity and Access

Primary question: Who or what is requesting access, and should it be allowed?

Practical outcome: Managed identities, strong authentication, least privilege, and controlled physical and logical access.

PR.AT

Awareness and Training

Primary question: Do people have the knowledge and skills required for their roles?

Practical outcome: A workforce prepared to recognize risk and perform security responsibilities correctly.

PR.DS

Data Security

Primary question: How is information protected wherever it exists or moves?

Practical outcome: Protected data at rest, in transit, in use, and in recoverable backups.

PR.PS

Platform Security

Primary question: Are systems built, configured, maintained, logged, and retired securely?

Practical outcome: Hardened and supportable hardware, software, services, and development practices.

PR.IR

Infrastructure Resilience

Primary question: Can the environment withstand disruption and continue delivering critical services?

Practical outcome: Segmented, redundant, environmentally protected, and adequately sized infrastructure.

PR.AA

Identity Management, Authentication, and Access Control

Identity is now one of the primary control planes for modern organizations. Users, administrators, contractors, service accounts, APIs, workloads, devices, certificates, tokens, and other machine identities all require lifecycle management. The organization must know which identities exist, how they are proofed, what credentials are bound to them, what they can access, and how that access is reviewed and removed.

Effective access control combines strong authentication with authorization. Multi-factor authentication can reduce credential risk, but it does not correct excessive privileges, unmanaged service accounts, weak recovery processes, stale entitlements, or poor separation of duties. The objective is the minimum necessary access for the minimum necessary time, based on the risk of the interaction.

A mature identity program should include:

A controlled joiner, mover, and leaver process for employees, contractors, partners, and third parties.
Inventory and ownership of human and non-human identities, including service accounts, API credentials, certificates, tokens, workloads, and devices.
Risk-appropriate identity proofing, authentication, credential recovery, and federation.
Phishing-resistant authentication options for sensitive systems and higher-risk access.
Least privilege, separation of duties, privileged access management, and time-bound access where appropriate.
Regular entitlement reviews and rapid revocation when roles, risk, or employment status change.
Physical access controls aligned with the importance and sensitivity of the facility or asset.

The 2026 identity update

NIST finalized Special Publication 800-63 Revision 4 in 2025. The update recognizes syncable authenticators such as passkeys, expands fraud and identity-proofing guidance, addresses injection attacks and forged media, and adds continuous evaluation considerations.

The current authentication guidance requires applications assessed at Authentication Assurance Level 2 to offer a phishing-resistant option; AAL3 requires phishing-resistant authentication using a non-exportable key. Organizations do not need to force the same method on every system, but they should match authentication strength to business impact, privilege, transaction risk, and likely attack methods.

Our experience is that organizations often invest heavily in an identity platform without establishing a complete identity strategy. The tool may be modern while the underlying ownership, lifecycle, exception, and access-review processes remain fragmented.

PR.AT

Awareness and Training: prepare people for the work they actually perform

Awareness and Training is not limited to an annual video and a simulated phishing email. The Category asks organizations to give personnel the knowledge and skills required to perform their cybersecurity responsibilities. That includes general users, but it also includes specialized roles such as administrators, developers, finance teams, executives, help desk staff, physical security personnel, incident responders, and third parties with access to important systems or data.

Email remains an important attack channel, but modern awareness programs must also address phone-based social engineering, text messages, QR codes, collaboration platforms, fraudulent support requests, MFA fatigue, credential recovery abuse, vendor impersonation, and convincing synthetic audio or video.

Training should be:

Role-based: tied to the decisions and access associated with each role.
Risk-based: focused on likely attack methods and meaningful business consequences.
Continuous: reinforced when systems, threats, responsibilities, or policies change.
Testable: measured through exercises, simulations, knowledge checks, and observed behavior.
Actionable: clear about how to verify suspicious requests and report possible incidents quickly.

Where organizations commonly fall short is treating completion as the success metric. Completion proves that content was delivered. It does not prove that people can recognize a relevant threat, follow the correct escalation path, or perform a specialized security task under pressure.

PR.DS

Data Security: protect information throughout its use and lifecycle

Data Security protects the confidentiality, integrity, and availability of information according to the organization’s risk strategy. NIST CSF 2.0 explicitly addresses data at rest, data in transit, data in use, and backups. The control strategy should follow the data across endpoints, applications, databases, cloud services, collaboration tools, development environments, third parties, and removable media.

Encryption is important, but it is not the entire program. Organizations also need data discovery and classification, access control, key and certificate management, integrity validation, retention rules, secure disposal, leakage prevention, production-data restrictions, monitoring, and tested recovery.

Four data states to protect

At rest: stored information in databases, files, endpoints, cloud storage, backups, images, and removable media.

In transit: information moving across internal networks, the internet, APIs, integrations, email, and third-party connections.

In use: information being processed in memory, displayed to a user, queried by an application, or handled by an authorized workload.

In backup: recoverable copies that are created, protected, maintained, separated from production risk, and proven through restore testing.

Backups are a protection control, not an assumption

A backup that has never been restored is an untested hypothesis. NIST’s 2026 OT Backup Quick Start Guide, SP 1339, reinforces the need to integrate backups with change management, create them regularly, test them, and review them during recovery exercises. The same operating principle is useful beyond OT: the organization should know what is backed up, how often, where copies are stored, who can alter them, how they are isolated, and whether recovery meets the business requirement.

Our experience is that data-security gaps usually begin upstream. The organization cannot apply consistent safeguards when it lacks a reliable data inventory, current flow diagrams, ownership, classification, and a clear definition of what requires protection.

PR.PS

Platform Security: harden and maintain the full technology stack

Platform Security covers the hardware, firmware, operating systems, applications, cloud services, containers, mobile platforms, SaaS products, and other physical or virtual technology that supports the organization. NIST CSF 2.0 emphasizes secure configuration, software and hardware maintenance, log generation, prevention of unauthorized software, and secure development practices.

The objective is not perfect hardening. It is a controlled platform lifecycle: establish an approved baseline, deploy securely, detect drift, patch according to risk, remove unnecessary functionality, replace unsupported technology, make logs available for monitoring, and retire systems without leaving data or access behind.

Platform protection should cover:

Tested secure configuration baselines and monitoring for unauthorized drift.
Routine and emergency patching tied to vulnerability risk and business criticality.
End-of-life planning for hardware, software, services, and dependencies.
Application allowlisting or other execution controls where risk warrants it.
Integrity and source verification before software is installed or deployed.
Useful logs from operating systems, applications, identity services, infrastructure, and cloud platforms.
Secure software-development practices from design through maintenance and disposal.

Cloud does not eliminate platform responsibility

Moving to cloud or SaaS can remove unsupported infrastructure and transfer some operational responsibilities to a provider. It does not eliminate the customer’s responsibilities for identity, configuration, data protection, integration, logging, tenant security, or supplier oversight. The exact boundary changes by service model and contract.

Where organizations commonly fall short is coordination. Platform protection crosses business owners, developers, infrastructure, networking, cloud engineering, service providers, security, and risk teams. Without common baselines, ownership, patch targets, exceptions, and end-of-life decisions, gaps remain open because each team assumes another team owns them.

PR.IR

Technology Infrastructure Resilience: design for adverse conditions

Protection is often described as preventing an attack. Technology Infrastructure Resilience addresses the harder reality: some failures, disruptions, and compromises will still occur. The architecture must limit their reach, preserve critical services, and provide enough capacity and redundancy to operate through adverse conditions.

NIST includes logical protection of networks and environments, protection from environmental threats, mechanisms that meet resilience requirements, and adequate resource capacity. In practice, that means segmentation, controlled trust boundaries, endpoint-health checks, redundancy, load balancing, failover, environmental protection, geographic considerations, capacity monitoring, and removal of single points of failure.

Resilience questions worth asking

Can a compromised user, endpoint, workload, or vendor connection move directly into critical systems?
Which systems, providers, regions, identity services, networks, or power sources are single points of failure?
Are failover mechanisms tested under realistic load and dependency conditions?
Can security controls continue operating when primary infrastructure is degraded?
Do capacity forecasts include incident conditions, recovery operations, and denial-of-service scenarios?
Are service-provider resilience commitments documented, monitored, and tested?

Defense in depth is valuable when controls are intentionally connected to interrupt different stages of an attack. Simply accumulating overlapping tools can create cost and complexity without resilience. Architecture, ownership, dependency mapping, testing, and clear failure assumptions are what turn multiple controls into a working defensive system.

Current guidance

What PROTECT means in practice in 2026

The five PROTECT Categories remain unchanged, but the surrounding implementation guidance has matured. Four developments are particularly relevant:

Identity guidance caught up with modern authentication. NIST SP 800-63 Revision 4 now addresses passkeys, phishing-resistant options, stronger fraud controls, forged media, federation, and continuous evaluation.
Ransomware protection is framed across the entire CSF. NIST published IR 8374 Revision 1 in June 2026, providing a CSF 2.0 Community Profile for assessing ransomware readiness and building countermeasures.
Backups are being treated as an operating discipline. NIST SP 1339 emphasizes regular creation, change-management integration, testing, and recovery exercises for OT backups.
Protection is part of incident readiness. NIST SP 800-61 Revision 3 connects safeguards across the CSF to fewer incidents, lower impact, and more effective detection, response, and recovery.

The larger message is that protection must be measurable and adaptable. Organizations should know which risk each safeguard addresses, whether the safeguard operates as intended, what evidence it produces, how it fails, and what happens when the environment changes.

Practical PROTECT checklist

Use these questions to pressure-test whether safeguards are actually working:

01. Are all human, service, workload, device, token, and certificate identities inventoried and assigned an owner?

02. Does authentication strength match the privilege, business impact, and likely attack method?

03. Are access rights reviewed, time-limited where appropriate, and removed promptly when circumstances change?

04. Is security training tailored to real roles, attack channels, and escalation responsibilities?

05. Do we know which sensitive data we hold and how it is protected at rest, in transit, in use, and in backup?

06. Can backups be restored within the business requirement, and has that been demonstrated through testing?

07. Are secure baselines, patch targets, logging requirements, and end-of-life decisions consistently enforced?

08. Can unauthorized software, insecure configuration changes, and deviations from approved baselines be prevented or detected?

09. Are critical networks, cloud environments, suppliers, and workloads segmented according to trust and business impact?

10. Have redundancy, failover, environmental protection, and capacity controls been tested under adverse conditions?

The bottom line

PROTECT is where cybersecurity strategy becomes operational. Identities are controlled, people are prepared, data is safeguarded, platforms are hardened, and infrastructure is designed to withstand disruption.

The strongest programs do not assume these safeguards will be perfect. They verify performance, detect control failures, preserve evidence, limit blast radius, and build enough resilience to keep important services operating. Those capabilities create the foundation for the next CSF Function: DETECT.

Frequently asked questions

NIST CSF 2.0 PROTECT FAQs

What is the PROTECT Function in NIST CSF 2.0?

PROTECT is the Function used to apply safeguards that manage cybersecurity risk. It covers identity and access, workforce training, data protection, platform security, and resilient technology infrastructure.

What are the five Categories within PROTECT?

The five Categories are Identity Management, Authentication, and Access Control (PR.AA); Awareness and Training (PR.AT); Data Security (PR.DS); Platform Security (PR.PS); and Technology Infrastructure Resilience (PR.IR).

What is the difference between IDENTIFY and PROTECT?

IDENTIFY develops an understanding of assets, threats, vulnerabilities, dependencies, and current risk. PROTECT applies safeguards according to those priorities. IDENTIFY determines what matters and why; PROTECT determines how the organization will reduce the likelihood or impact of harm.

Does MFA satisfy the Identity and Access Category?

No. MFA is one authentication control. PR.AA also covers identity lifecycle management, proofing, credentials, federation, authorization, least privilege, separation of duties, entitlement review, service and device identities, and physical access.

Are backups part of PROTECT or RECOVER?

Both Functions are involved. Creating, protecting, maintaining, and testing backups is a Data Security outcome under PROTECT. Restoring affected assets and operations is addressed under RECOVER. A mature program connects the two through tested recovery requirements.

Does NIST CSF 2.0 require a zero-trust architecture?

No. The CSF describes outcomes rather than prescribing one architecture. Zero-trust principles can support PROTECT through explicit verification, least privilege, segmentation, device-health checks, and minimum necessary access, but each organization chooses safeguards appropriate to its risk and environment.

How often should security training and protection controls be reviewed?

They should be reviewed on a defined schedule and whenever systems, roles, threats, suppliers, business processes, or risk assumptions change. Annual activity may provide a baseline, but high-change or high-risk environments require more frequent reinforcement, testing, and control validation.

Primary NIST references

Achieve Better Cybersecurity

Are your safeguards aligned with your actual risk?

SEVN-X Framework Assessments evaluate how your controls perform against NIST CSF 2.0, identify meaningful gaps, and turn the results into a prioritized remediation roadmap your organization can use.

Explore Framework Assessments

Advisory Services, Cyber Strategy

NIST Cybersecurity Framework 2.0: Protect | 2026 Update