The Endpoint Security Maturity Model

Introduction

A maturity model is a way of turning a set of technical states into a number somebody outside the team can act on, and it is useful for exactly that and dangerous beyond it. This section covers the five levels, how to score each layer separately, and what target to set. You will finish able to produce a score you can defend line by line, and to say why a single number for an estate is nearly always wrong.

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 ES9. 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, detecting the behavior of any credential dumping tool, not Mimikatz alone, 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 threat landscape rather than by incidents or audits.

Stated as configuration rather than as adjectives, the five levels stop being a vocabulary and become a checklist somebody can disagree with, which is the only form in which a maturity score is worth presenting.

1  INSTALLED     product deployed, defaults everywhere. the
                 compliance report is accurate and the posture
                 is generation one.
2  CONFIGURED    policies applied, telemetry arriving, controls
                 in AUDIT. you can see; you are not stopping
                 anything.
3  ENFORCING     hardening in block with owned exclusions,
                 detections written for your own techniques,
                 retention sized to your dwell time.
4  MEASURED      coverage tracked, drift alerted, exclusions
                 expiring, reviews producing decisions.
5  ADAPTIVE      tested against real techniques, controls
                 changed in response to what the tests find.

THE JUMP THAT MATTERS IS 2 TO 3. Everything below it is visible
in a console; everything at or above it is visible only on a
device.

Read those levels as configuration states rather than as adjectives. The difference between level two and level three is not "more mature", it is a specific set of things that are enforcing rather than auditing, and being able to name them is what stops the model becoming a vocabulary exercise. If you cannot say what would have to change to move a layer up one level, the score is a description rather than a plan.

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.

  1 -> 2   weeks. onboarding, telemetry, policies applied.
           mostly project work with a clear end.
  2 -> 3   MONTHS. hardening enforced, detections written,
           exclusions owned. this is where the work is, and
           where most estates stop without deciding to.
  3 -> 4   quarters. automation, integration, measured
           improvement cycles. needs the previous level to be
           stable, not merely reached.
  4 -> 5   continuous. threat-informed, tested against real
           techniques, and requires people whose job this is
           rather than people who also do this.

LEVEL 3 IS THE RIGHT TARGET FOR MOST ESTATES. Level 5 is not
better in the abstract; it is a staffing commitment, and an
estate at level 3 with the exclusions under control is in a
stronger position than one at level 4 that cannot say what its
exemptions are for.

The target is a resourcing decision rather than a security one, and treating it as a security decision is how estates commit to level 4 and stall at 2. Pick the level you can hold, not the one you can reach: a layer that reaches level 3 and drifts back to 2 because nobody owns the exclusions has cost more than it bought, since the enforcement was reverted and the confidence was not.

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 more than 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.

  TO AN EXECUTIVE     the number and its direction. "hardening
                      moved 2 to 3 this quarter, detection did
                      not." they are buying a trend, and the
                      trend is what a single figure is good for.
  ------------------------------------------------------------------
  TO THE IT TEAM      which layers need them. onboarding needs
                      device management, hardening needs a change
                      window, response needs an on-call path.
                      the model names the dependency without
                      making it a security argument.
  ------------------------------------------------------------------
  THE MECHANISM       quarterly re-scoring. a layer that has not
                      moved in two quarters is either finished or
                      abandoned, and the model forces somebody to
                      say which.

The last line is what makes it more than a presentation. A score that is produced once is a snapshot somebody puts in a deck; a score produced every quarter creates a question that has to be answered about any layer that stood still, and that question is the only accountability the model actually supplies.

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. SEC409 Endpoint Security Operations 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.

Scored against the five levels, Northgate sits where most estates that deployed once and stopped sit.

Scoring layers separately is what stops the model flattening the thing you most need to see. An estate at an average of 3 might be enforcing well and unable to investigate anything, and the average hides exactly the imbalance that decides what to do next. Score five layers, report five numbers, and let the executive summary be the lowest one rather than the mean.

This takes half an hour and produces the page that goes in front of whoever funds the next twelve months. Do it before the course rather than after, because the comparison is the useful part.

Keep it with the phase coverage table from 0.2, the four metrics from 0.4 and the estate description from 0.6. Those four pages are the whole of your starting position, and producing them takes an afternoon that pays for itself the first time somebody asks where the money should go.