The Endpoint Security Maturity Model

The five levels

The maturity model is a practitioner's assessment framework designed specifically for endpoint security engineering in M365 E5 environments. The five levels map to the deployment sequence taught across ES2 through ES15. Each level has binary pass/fail criteria so the assessment produces an unambiguous result, not a subjective opinion. The model is cumulative: you cannot be Level 3 without meeting all Level 2 criteria. An organization with 20 custom detection rules but no ASR enforcement has advanced detection on top of an unprotected endpoint — the attacker bypasses the detection by exploiting the missing prevention layer.

Level 1 — Ad Hoc. You have an EDR product deployed on most devices. AV runs with default settings. Security controls are not systematically configured. Detection depends entirely on the vendor's built-in alerting. No custom detection rules exist. No documented policies for endpoint security operations. Incident response for endpoint-related incidents is ad hoc — different analysts handle similar incidents differently, and the outcome depends on who is on shift. This is where approximately 70% of M365 E5 organizations operate. NE is at Level 1.

Level 2 — Baseline. MDE onboarded on 100% of managed devices with validated sensor health. AV cloud protection at High+ with Block at First Sight enabled. At least the "safe set" ASR rules in block mode — LSASS protection, vulnerable driver blocking, USB untrusted process blocking. LAPS deployed across the fleet. Compliance policies enforcing Conditional Access for at least standard users. Device health monitoring dashboard operational with daily automated checks. This level provides measurable prevention improvement over default configuration. The jump from Level 1 to Level 2 is the highest-impact transition in the model — it transforms the endpoint from a passive sensor into an active defense.

Level 3 — Managed. Most applicable ASR rules in block or warn mode with documented exclusions in the exclusion register. At least 10 custom detection rules with documented TP rates above 30%. AIR configured with deliberate automation levels per alert type, not all at the default semi-automated setting. Monthly hunting cadence with documented hunts and a hunt-to-detection pipeline — findings from hunts are converted into detection rules. Sysmon deployed on all endpoints with the SwiftOnSecurity baseline. Advanced audit policies and PowerShell ScriptBlock logging configured. This level provides both prevention and detection capability, plus the forensic readiness that makes investigations productive.

Level 4 — Optimized. Twenty or more custom detection rules covering the major ATT&CK tactics relevant to the organization's threat model. Weekly hunting cadence with hunt-to-detection pipeline operational — each hunt either confirms existing coverage or produces a new detection rule. Cross-platform coverage with servers and Linux endpoints onboarded to MDE. Sentinel integration with cross-workload detection rules that correlate endpoint, identity, and email signals. Automation playbooks for high-confidence automated response — device isolation on ransomware detections, investigation package collection on high-severity alerts. Vulnerability management operationalized with tracked remediation and documented exceptions. CIS hardening baselines applied across the fleet. This level represents a complete, integrated endpoint security architecture where all five layers of the stack from Section 0.3 are active and measured.

Level 5 — Adaptive. Threat intelligence drives detection priorities — new advisories are scored against the existing backlog and integrated into the detection engineering sprint. Red team or purple team exercises validate the endpoint security stack regularly, with findings driving control improvements rather than just reports. Evasion-aware detections that anticipate and account for attacker bypass techniques — not just detecting Mimikatz, but detecting the behavior of any credential dumping tool regardless of the binary used. Continuous validation using Atomic Red Team or similar testing frameworks that confirm controls work after every change. Governance framework with documented policies, exception management, change management, and compliance mapping. Detection lifecycle management with versioning, review, and retirement of stale rules. This level represents continuous improvement driven by the evolving threat landscape rather than by incidents or audits.

Setting realistic targets

The target level should be proportional to the threat model and the available engineering resources. Level 3 represents a significant security improvement over Level 1 and stops the majority of attacks that M365 E5 environments face. Level 4 and Level 5 are for organizations facing advanced, targeted threats — nation-state actors, organized crime groups with custom tooling, sophisticated insider threats. A 50-person professional services firm facing commodity threats needs Level 3. A defense contractor facing state-sponsored espionage needs Level 5. NE, as a defense supply chain company, needs Level 4 at minimum.

The engineering effort to progress from Level 1 to Level 4 at NE's scale — 865 endpoints, 12 servers, 8 Linux servers — requires approximately 200–300 hours of dedicated endpoint security engineering work across the 90-day plan. That translates to roughly 15–25 hours per week. If you have a full-time security engineer, Level 4 at 6 months is achievable with margin for unexpected issues. If endpoint security engineering is 20% of one person's role — roughly 8 hours per week — target Level 3 at 6 months and Level 4 at 12 months. Overcommitting and failing to reach Level 4 is worse than committing to Level 3 and delivering it. The maturity model makes this tradeoff explicit: the criteria for each level are public, measurable, and verifiable. When management asks "are we on track?" the answer is not a subjective assessment — it is a score against documented criteria that either pass or fail.

The model as a communication tool

The maturity model serves a dual purpose: engineering planning tool and executive communication tool. When presenting to the CISO, the model provides the three-part answer management always asks for: where we are (Level 1), where we need to be (Level 3 minimum, Level 4 target), and what it takes to get there (the 90-day plan with specific controls per phase). A spider diagram showing current scores overlaid with target scores makes the scope of the improvement instantly visible. The quarterly re-assessment shows progress — or lack of it.

When presenting to the IT team, the model identifies which layers require their collaboration. Onboarding requires the endpoint management team. Compliance enforcement requires Intune administrators. Server hardening requires the infrastructure team. Each layer's improvement has specific dependencies on other teams, and the maturity model makes those dependencies explicit so nobody is surprised when the security team needs their time.

The quarterly re-assessment is not just measurement — it is the accountability mechanism. If a layer's score does not improve between quarters, either the planned work was not executed (a resource issue requiring escalation), the work was executed but ineffective (an engineering issue requiring investigation), or the target was unrealistic (a planning issue requiring adjustment). Each explanation drives a different corrective action.

Scoring each layer independently

The maturity model is not a single number — each layer of the five-layer stack from Section 0.3 is scored independently on a 1–5 scale, and the per-layer scores reveal where investment provides the most improvement. A composite score converts the five layer scores into a percentage for executive reporting: Level 1 criteria worth 20 points, Level 2 worth 20, through Level 5 worth 20, for a total of 100. Partial credit within each level is permitted — meeting 4 of 6 Level 2 criteria scores 13/20 for that level. The composite score gives management the single number they want. The per-layer breakdown gives the engineering team the actionable detail they need.

Onboarding at NE (score 2/5). MDE is deployed to 90% of endpoints but not all. Some servers are missing. Linux has no coverage. Device health is checked manually when someone remembers. Moving to Baseline requires 100% onboarding across all device types, automated health monitoring with alerting on sensor degradation, and device groups configured for differentiated policy application. The effort is moderate — Module ES2 covers this in 2–3 weeks of focused work, and the result is the prerequisite for every subsequent control.

ASR at NE (score 1/5). No ASR rules are in block mode. None are in audit mode either — the rules simply are not configured. No ASR monitoring exists. Moving to Baseline requires at least the safe set of ASR rules in block mode with documented exclusions — LSASS protection, vulnerable driver blocking, USB untrusted process blocking. Moving to Managed requires 12 or more rules in block mode with an established audit data analysis cadence and a maintained exclusion register. The effort is significant because audit data collection takes 2–4 weeks before enforcement decisions can be made — but the security improvement per hour of engineering work is the highest of any layer.

Detection at NE (score 1/5). Zero custom detection rules. Complete dependence on MDE's built-in detections. No hunting activity — the Advanced Hunting console has not been accessed in six months. Moving to Managed requires at least 10 custom detection rules with documented TP rates above 30%, a monthly hunting cadence, and a hunt-to-detection pipeline where findings from hunts are converted into automated detection rules. The effort is significant but can run in parallel with ASR deployment: while the audit data collection period runs for ASR rules, the security engineer can write and test custom detection rules in Advanced Hunting.

Forensic readiness at NE (score 1/5). Default audit policies, no PowerShell ScriptBlock logging, no Sysmon. Moving to Managed requires advanced audit policies deployed through Intune, ScriptBlock logging enabled, and Sysmon deployed with a tuned baseline. The effort is moderate — Module ES11 covers the deployment in 1–2 weeks — and the result is the evidence foundation that every investigation depends on. Deploy forensic readiness in parallel with detection engineering so that the evidence is being collected before the first incident that requires it.

Response at NE (score 2/5). MDE provides device isolation, live response, and AIR at default settings. Moving to Managed requires deliberate AIR automation levels per alert type — not the default semi-automated for everything — and documented response procedures for the most common alert types. Moving to Optimized requires automation playbooks that trigger device isolation, investigation package collection, and indicator blocking based on high-confidence detections without analyst intervention.

The per-layer scoring reveals the improvement path: onboarding is closest to target and should be completed first because everything depends on it. ASR and detection need the most work but provide the highest security improvement per engineering hour. Forensic readiness has low blast radius and should be deployed in parallel with detection engineering rather than sequentially after it.

The maturity score is measurable, not subjective. A KQL query that checks fleet-wide control deployment gives you the empirical data for each layer's score.

// Maturity Level 2 readiness — fleet onboarding and sensor health
DeviceInfo
| where Timestamp > ago(1d)
| summarize arg_max(Timestamp, *) by DeviceId
| summarize
    Total = count(),
    Active = countif(SensorHealthState == "Active"),
    Inactive = countif(SensorHealthState == "Inactive"),
    OnboardPct = round(countif(SensorHealthState == "Active") * 100.0 / count(), 1)
// Level 2 requires OnboardPct ≥ 98%. NE is at 90%.

This query produces the Level 2 onboarding metric directly. If OnboardPct is below 98%, the first engineering task is closing the onboarding gap — identifying the unmanaged devices, remediating the inactive sensors, and verifying coverage before deploying any controls that depend on fleet-wide telemetry. The maturity model is only actionable when each level has a measurable threshold and a query that produces the current number.