NIST CSF 2.0 Detect Function: DE.CM and DE.AE Explained

Detect is the Function where owning a SIEM is most often mistaken for meeting the outcome. CSF 2.0 (NIST CSWP 29, 26 February 2024) defines Detect as the Function in which possible cybersecurity attacks and compromises are found and analysed. It shrank from three Categories in CSF 1.1 to two, Continuous Monitoring and Adverse Event Analysis, with 11 Subcategories, and the old Detection Processes Category was dissolved into Govern, Identify and Detect itself. This guide works through every Detect Subcategory with NIST's Implementation Examples, shows where the 1.1 outcomes went, sets out the evidence and metrics an assessor should look for, maps Detect to SP 800-53 Rev 5, ISO/IEC 27001:2022 and MITRE ATT&CK, and covers identity-based detection, which is where most current intrusions show up first. It is for SOC leads, detection engineers, security architects and auditors who already know the CSF basics.

Key takeaways

Detect has two Categories and 11 Subcategories: DE.CM Continuous Monitoring (DE.CM-01, 02, 03, 06, 09) and DE.AE Adverse Event Analysis (DE.AE-02, 03, 04, 06, 07, 08).
Incident declaration is a Detect outcome. DE.AE-08 expects incidents to be declared when adverse events meet defined criteria, replacing the 1.1 alert threshold outcome.
Monitoring is grouped by what is watched, not by threat type: networks, the physical environment, personnel and technology use, external providers, and computing assets and their data.
Logging itself sits in Protect. PR.PS-04 (log records are generated and made available for continuous monitoring) is the precondition; Detect is about using those records.
Authentication monitoring is named explicitly. A DE.CM-09 Implementation Example is monitoring authentication attempts for attacks against credentials and unauthorised credential reuse, which covers non-human credentials too.

What changed from CSF 1.1

The CSF 2.0 catalogue records where each withdrawn 1.1 outcome went:

CSF 1.1 outcome	Now in CSF 2.0
DE.AE-01 Network baseline established	ID.AM-03 (data flow representations)
DE.AE-05 Incident alert thresholds established	DE.AE-08 (incident declaration criteria)
DE.CM-04 Malicious code detected; DE.CM-05 Unauthorised mobile code detected	DE.CM-01, DE.CM-09
DE.CM-07 Monitoring for unauthorised personnel, connections, devices and software	DE.CM-01, DE.CM-03, DE.CM-06, DE.CM-09
DE.CM-08 Vulnerability scans performed	ID.RA-01
PR.DS-06 and PR.DS-08 Integrity checking of software, firmware, information and hardware	DE.CM-09 (with PR.DS-01 and ID.RA-09)
DE.DP-01 Detection roles defined	GV.RR-02
DE.DP-02 Detection activities comply with requirements	DE.AE
DE.DP-03 Detection processes tested	ID.IM-02
DE.DP-04 Event detection information communicated	DE.AE-06
DE.DP-05 Detection processes continuously improved	ID.IM, ID.IM-03

Two consequences for assessments: vulnerability scanning is no longer evidence for Detect, and testing and improving detection (purple teaming, detection validation) is scored under ID.IM-02 and ID.IM-03. See the NIST CSF 2.0 Identify Function.

DE.CM Continuous Monitoring

Category statement: assets are monitored to find anomalies, indicators of compromise and other potentially adverse events. Implementation Examples are paraphrased from the CSF 2.0 Core; CSWP 29 states the CSF does not prescribe how outcomes should be achieved, so they are illustrations, not a checklist.

Subcategory	Outcome	NIST Implementation Examples (summarised)	Typical telemetry
DE.CM-01	Networks and network services are monitored to find potentially adverse events	Monitor DNS, BGP and other network services; detect unauthorised endpoints on wired and wireless networks; find rogue wireless networks; compare flows against baselines; monitor for zero trust posture changes	DNS query logs, flow records, NDR, wireless intrusion detection, firewall and proxy logs
DE.CM-02	The physical environment is monitored to find potentially adverse events	Badge reader logs for unusual patterns and failures; visitor records; tamper checks on locks and alarms; alarms, cameras and guards	Physical access control system logs, CCTV, alarm events
DE.CM-03	Personnel activity and technology usage are monitored to find potentially adverse events	Behaviour analytics for anomalous user activity and insider threat; logical access logs for unusual patterns and failures; monitor deception technology, including decoy accounts	Identity provider sign-in logs, UEBA, honeytoken and decoy alerts
DE.CM-06	External service provider activities and services are monitored to find potentially adverse events	Monitor remote and onsite administration by external providers; monitor cloud, ISP and other providers for deviations from expected behaviour	Privileged session records, SaaS and cloud audit logs, third-party access logs
DE.CM-09	Computing hardware and software, runtime environments and their data are monitored to find potentially adverse events	Monitor email, web, file sharing and collaboration for malware, phishing and exfiltration; monitor authentication attempts for credential attacks and reuse; detect configuration drift; detect tampering; endpoint health checks before access is granted	EDR, email and web gateway logs, cloud control plane logs, configuration and integrity monitoring

DE.CM-02 is often scored "not applicable" by cloud-first organisations, but the outcome still applies to offices, data rooms and any facility that hosts network equipment. DE.CM-06 is the most under-assessed: few organisations can show monitoring of what their managed service providers and SaaS vendors do inside their tenants. See the SIEM Guide and the UEBA Guide.

DE.AE Adverse Event Analysis

Category statement: anomalies, indicators of compromise and other potentially adverse events are analysed to characterise the events and detect cybersecurity incidents.

Subcategory	Outcome	NIST Implementation Examples (summarised)
DE.AE-02	Potentially adverse events are analysed to better understand associated activities	SIEM or other tools continuously monitor logs for known malicious and suspicious activity; use current threat intelligence in log analysis; manual review where automation is insufficient; report findings
DE.AE-03	Information is correlated from multiple sources	Transfer logs to a small number of log servers; use event correlation technology; use threat intelligence to correlate across sources
DE.AE-04	The estimated impact and scope of adverse events are understood	Tools or analysts estimate impact and scope, then review and refine the estimates
DE.AE-06	Information on adverse events is provided to authorised staff and tools	Alerts go to the SOC, responders and response tools; responders can access findings at all times; tickets created automatically or manually
DE.AE-07	Cyber threat intelligence and other contextual information are integrated into the analysis	Feed intelligence and asset inventory information to detection technologies and people; rapidly acquire and analyse supplier vulnerability disclosures
DE.AE-08	Incidents are declared when adverse events meet the defined incident criteria	Apply incident criteria to known and assumed characteristics of activity; account for known false positives

DE.AE-08 is the hand-off to Respond

The incident criteria themselves should be defined in the incident response plan (an ID.IM-04 outcome), and the declared incident is then triaged and validated under RS.MA-02. Writing the criteria down (for example: confirmed use of a privileged credential from an unmanaged device, or any data leaving via an unapproved channel above a set volume) is what lets an analyst declare consistently at 3am. NIST SP 800-61 Rev 3 (April 2025) frames incident response, including detection, as a CSF 2.0 Community Profile. See the NIST CSF 2.0 Respond Function.

Where identity fits

Many intrusions involve valid credentials (MITRE ATT&CK T1078 Valid Accounts, with T1078.004 for cloud accounts), so Detect outcomes for personnel activity and authentication carry much of the load.

DE.CM-03 and DE.CM-09 for non-human identities: baseline service accounts, API keys and workload identities by source, time, API calls and data volume; their behaviour is more regular than people's, so deviations are easier to see. See the ITDR Guide.
Credential reuse from new locations: the 2024 Snowflake customer breaches used infostealer credentials against accounts without MFA; authentication monitoring for unfamiliar sources and clients is the DE.CM-09 outcome that would surface such logins.
Deception for identities: DE.CM-03 names monitoring of decoy accounts; canary API keys and tokens extend the same idea to machine credentials. See the Honeytokens and Canary Credentials Guide.
DE.CM-06 for third-party tokens: OAuth applications and supplier integrations act inside your tenant; their API activity needs the same monitoring as a provider's administrators.

Implementing Detect step by step

Confirm logging prerequisites: PR.PS-04 log generation for identity providers, cloud control planes, endpoints, email and network services, with protected storage. The joint guidance Best Practices for Event Logging and Threat Detection, led by Australia's ASD's ACSC with CISA, the NCSC and other agencies, is a practical baseline. See the Log Management and Retention Guide.
Map coverage to assets and threats: use the ID.AM inventory and ID.RA-03 threat records to decide which assets and which ATT&CK techniques need detection first.
Centralise and correlate (DE.AE-03): collect to a small number of platforms, normalise identities and asset names, and enrich with inventory and intelligence (DE.AE-07).
Write detections as code: version, test and review analytics, with a named owner per rule. See the Detection Engineering Guide.
Define incident criteria (DE.AE-08): agree with incident response which conditions require declaration and who can declare.
Route and ticket (DE.AE-06): alerts reach the SOC and response tooling with context; nothing lives only in a console.
Extend to providers (DE.CM-06): obtain audit logs from SaaS, cloud and managed service providers and monitor privileged third-party sessions.
Validate continuously: run adversary emulation or detection tests and track results under ID.IM-02; retire rules that never fire and fix those that fail.

Small versus large organisations: a small business can meet most Detect outcomes through the alerting built into its endpoint protection, email service and identity provider, a managed detection and response service, and a short list of incident criteria. Large organisations need detection engineering, coverage measurement against ATT&CK and provider log integration, and their risk is volume: alert queues that bury DE.AE-08 decisions.

Evidence and measurement

Subcategory	Weak evidence	Strong evidence
DE.CM-01, DE.CM-09	Tool licences	Log source inventory showing coverage of critical assets, with gaps tracked
DE.CM-03	Sign-in logs retained	Active analytics on user and service account behaviour with recent triaged alerts
DE.CM-06	Contract right to audit	Provider audit logs ingested and alerting on third-party privileged activity
DE.AE-02, DE.AE-03	A SIEM dashboard	Version-controlled detection rules with owners, test results and correlation across sources
DE.AE-07	An intelligence subscription	Indicators and asset context visibly enriching alerts and changing priority
DE.AE-08	Analyst judgement	Written incident criteria and declaration records that cite them

Metrics that show Detect is working

Log source coverage: percentage of critical assets and identity systems sending required logs.
Technique coverage: percentage of prioritised ATT&CK techniques with a tested detection.
Time to detect: median time from first malicious activity to alert, from incidents and exercises.
Alert fidelity: true positive rate per detection rule, reviewed monthly.
Declaration time: median time from alert to incident declaration under DE.AE-08.
Silent rules: number of rules that failed validation or have not fired in tests.

See the Detection Engineering Maturity Model for a staged view.

Mapping to other frameworks

For formal crosswalks use NIST's CSF 2.0 Informative References in the CSF 2.0 Reference Tool. This table is an orientation by control purpose.

Detect outcome	SP 800-53 Rev 5 (related)	ISO/IEC 27001:2022 Annex A	CIS Controls v8.1
DE.CM-01	SI-4 System Monitoring	8.16 Monitoring activities, 8.20 Networks security	Control 13 Network Monitoring and Defense
DE.CM-02	PE-6 Monitoring Physical Access	7.4 Physical security monitoring	Not a specific Control
DE.CM-03	AU-6 Audit Record Review, Analysis, and Reporting, SI-4	8.15 Logging, 8.16	Control 8 Audit Log Management
DE.CM-06	SA-9 External System Services, SI-4	5.22 Monitoring, review and change management of supplier services	Control 15 Service Provider Management
DE.CM-09	SI-3 Malicious Code Protection, SI-7 Software, Firmware, and Information Integrity, SI-4	8.7 Protection against malware, 8.16	Controls 8, 10 and 13
DE.AE-02, 03, 04	AU-6, IR-4 Incident Handling, CA-7 Continuous Monitoring	5.25 Assessment and decision on information security events	Control 8
DE.AE-06	IR-5 Incident Monitoring, SI-4	6.8 Information security event reporting	Control 17 Incident Response Management
DE.AE-07	PM-16 Threat Awareness Program, SI-5 Security Alerts, Advisories, and Directives	5.7 Threat intelligence	Not a specific Control
DE.AE-08	IR-4, IR-8 Incident Response Plan	5.25	Control 17

Log protection (SP 800-53 AU-9 Protection of Audit Information) and generation (AU-2 Event Logging, AU-12 Audit Record Generation) support PR.PS-04 rather than Detect directly. NIST SP 800-92 Rev 1, the Cybersecurity Log Management Planning Guide, was still shown as an Initial Public Draft (October 2023) when checked in November 2026, so treat it as draft guidance.

Common failure patterns

Collecting without analysing: logs reach the SIEM but no tested analytics run on them, so DE.CM is claimed and DE.AE is not met.
Human-only identity analytics: behaviour models cover employees while service accounts and API keys are excluded as "noisy".
No provider visibility: SaaS and managed service provider activity is outside monitoring, so DE.CM-06 is scored on contract terms alone.
Undefined declaration: without DE.AE-08 criteria, incidents are declared late or inconsistently, delaying Respond and any regulatory clocks.
Counting scans as detection: carrying 1.1 DE.CM-08 evidence forward when vulnerability scanning now belongs in ID.RA-01.
Untested rules: detections break silently after log format or schema changes because nothing validates them.

Practitioner checklist

Score all 11 Detect Subcategories individually and move 1.1 DE.DP and DE.CM-08 evidence to its new home.
Confirm PR.PS-04 log generation for identity, cloud, endpoint, email and network sources.
Maintain a log source inventory mapped to critical assets.
Include service accounts, API keys and workload identities in behaviour analytics.
Ingest SaaS, cloud and managed service provider audit logs.
Manage detections as code with owners, tests and review dates.
Write incident declaration criteria and record which criterion each declaration met.
Measure technique coverage and time to detect, and validate detections regularly.

NIST CSF 2.0 Detect Function Guide: All 11 Outcomes Explained and Evidenced