Cyber Defense Matrix 2.0 · Function · PR

PROTECT(PR)

Access control, data security, platform security, resilience. The column where the largest share of security spend lands.

PROTECT is the NIST CSF 2.0 function that covers the preventive controls: identity and access management, data security, platform hardening, and resilience. In most organizations PROTECT is the biggest single column by spend, the widest by tool count, and the most prone to overlap — which makes it the highest-ROI column to rationalize.

What sits inside PROTECT

The NIST CSF 2.0 PROTECT categories are PR.AA (Identity, Authentication, Access), PR.AT (Awareness and Training), PR.DS (Data Security), PR.PS (Platform Security), and PR.IR (Infrastructure Resilience). In a mid-market stack these resolve to a familiar set of tool categories: identity providers, MFA, privileged access management, data loss prevention, encryption, endpoint configuration, patching, email security, cloud workload protection, backup and disaster recovery.

The breadth is the point — PROTECT is where an organization converts policy intent into deployed controls. It is also why the column tends to accumulate overlap. Multiple tools often claim to cover the same cell (e.g. email security: M365 Defender plus Proofpoint plus Abnormal) without any single one being retired.

Where PROTECT overlaps tend to hide

Identity is the most common overlap cluster. A typical stack has an IdP (Okta/Entra/Ping), an MFA product that predates the IdP (Duo, RSA SecurID), a PAM (CyberArk, Delinea, BeyondTrust), and a governance product (SailPoint, Saviynt). Two or three of these overlap on access certification, session management, or password vaulting. The rationalization opportunity is usually not 'remove a tool' — it is 'decide which tool owns which capability and stop funding the redundant half of the other.'

Data security is the second. DLP tools (Forcepoint, Symantec/Broadcom, Microsoft Purview), CASB (Netskope, Zscaler), cloud DSPM (Dig, Laminar, Normalyze), and the data-handling features of endpoint suites overlap extensively on 'scan for sensitive data and alert on movement.' Same-vendor suites do not count as overlap (CLAUDE.md §2 rule) but cross-vendor combinations are worth unwinding.

Endpoint is the third. Organizations that went through vendor consolidation often left legacy EPP running alongside EDR/XDR for a year after purchase and never removed it. Any two-vendor endpoint coverage that lasts longer than an agreed-upon migration window is spend without additional protection.

PROTECT × asset-row coverage patterns

The standard pattern for a mid-market stack is: PROTECT × Devices and PROTECT × Applications well-covered, PROTECT × Data and PROTECT × Users reasonably covered with one or two tools doing the heavy lift, PROTECT × Networks covered by NGFW + SASE, PROTECT × Cloud covered by CSPM/CNAPP, PROTECT × OT/IoT thin or absent, PROTECT × AI/ML absent, PROTECT × Supply Chain governed in GV.SC but with few actual PROTECT controls.

The weakest PROTECT cells are almost always in the extension rows (Cloud for organizations that are not cloud-native, OT/IoT for non-industrial organizations that have some IoT, AI/ML for everyone). These are where 'You Already Own the Fix' recommendations most often appear — existing tools have capabilities in these rows that were never enabled.

How to rationalize PROTECT without creating gaps

The conservative sequence: (1) document which tool owns which cell, (2) identify cells with cross-vendor overlap, (3) pick the tool whose lifecycle status is strongest and whose operational ownership is clearest, (4) migrate operations onto that tool, (5) only then terminate the redundant contract. This is the opposite of the default vendor-consolidation story, which assumes the cheapest tool wins. In practice the best-operated tool wins — changing tools mid-cycle is more disruptive than paying for a year of redundant licensing.

Frequently asked

Is MFA a PROTECT control or an IDENTIFY control?

PROTECT — specifically PR.AA (Identity, Authentication, Access). IDENTIFY is about knowing what identities exist. PROTECT is about controlling how those identities authenticate. MFA is a gating control on authentication, so it lives in PROTECT.

Do endpoint EDR tools cover PROTECT or DETECT?

Both, and they are sold as both. In the CDM 2.0 model, EDR's preventive features (application control, memory protection, USB blocking) map to PROTECT × Devices. Its detection features (behavioral analytics, threat hunting, process-tree inspection) map to DETECT × Devices. A single product can legitimately occupy two cells.

Should we have both an IdP and a PAM?

Yes, for most organizations above 200 employees. The IdP governs routine access to SaaS and internal apps. PAM governs privileged access to infrastructure, production systems, and break-glass accounts. They serve different risk profiles and different audit contexts. Below 200 employees the IdP's privileged-access features are often sufficient.

Is DLP still worth deploying?

Yes, but selectively. Legacy network DLP (Symantec, Forcepoint) is declining in value as traffic moves to SaaS. Microsoft Purview and CASB-native DLP cover the SaaS-to-SaaS flows that matter most. The honest question is whether anyone is tuning the DLP rules and acting on the alerts — if not, the cell is paper coverage.