The NE Endpoint Landscape

Introduction

Northgate Engineering is the estate this course works on, and this section is its honest starting position rather than its architecture diagram.

Every product is licensed, every product is installed, and almost nothing is configured beyond its defaults. That combination is not unusual and it is not the result of anybody being careless: it is what an estate looks like when procurement finished and engineering never started, which describes a large share of the organizations reading this.

You will finish able to count an estate four ways and explain why the four disagree, name the four gaps the rest of this course closes in the order an attacker meets them, and identify the population in your own fleet that is both the least protected and the most reachable.

Northgate is 810 staff across seven sites, with 865 Windows endpoints, 12 servers of which six are RHEL and two Ubuntu web hosts, and a Microsoft 365 E5 tenant carrying Entra ID, Intune, Sentinel and Defender XDR. That is the sentence the estate would use to describe itself and it is the least useful version of the count.

The useful version is four numbers that disagree. Devices in the asset register, devices in Entra ID, devices enrolled in Intune, and devices reporting into Defender. Each is produced by a different system for a different purpose and none is authoritative, so the gaps between them are the actual finding rather than an error to reconcile away.

Northgate, counted four ways

  asset register            902   finance's list, updated at purchase
  Entra ID device objects   871   includes 40 that have not signed in
                                  for over 90 days
  Intune enrolled           843   policy can reach these
  Defender reporting        779   telemetry exists for these

  gap, register to Defender 123   machines nobody is watching, or
                                  machines that no longer exist

Nobody in the organization can currently say which.

That last line is the point. A 123-device gap is either a serious visibility problem or a stale spreadsheet, and the two demand completely different responses. The work that resolves it is dull, it belongs at the start rather than the end of a program, and it is the reason the deployment sequence in ES0.7 opens with an inventory rather than with a control.

Note also which direction the gaps run. Every number gets smaller as it gets closer to being able to act: the register is the largest, and the population you can actually enforce policy on is smaller still. Any percentage you quote is a fraction of whichever denominator you chose, and choosing the smallest one flatters every figure you report.

Each gap also has a characteristic cause, which is what makes reconciling them tractable rather than endless. Register against Entra is usually disposals that were never written off, so it is finance's list being stale rather than machines being missing. Entra against Intune is devices that joined the directory and never enrolled, which happens on any estate that has ever allowed a manual join. Intune against Defender is the one that matters most, because those are managed machines where the sensor is failing or was never pushed, and every one of them takes policy and produces no telemetry.

Reconcile in that order and the work shrinks at each step. Most of the 123 turns out to be the first category, which is a records exercise, and the residue is a much smaller number of machines that are genuinely unwatched. Getting to that residue is a day's work and it changes every figure you report afterwards.

Deployed means the product is present, licensed, and reporting healthy. Engineered means somebody made decisions about it, wrote them down, and can defend them. The distance between those two states is invisible in every console, because a console reports the first and has no view of the second.

Northgate, as reported against as configured

  CONTROL                REPORTED          ACTUAL
  Antivirus              100% coverage     defaults. cloud protection
                                           off on 214 devices
  MDE onboarding         90%               779 of 865. the missing 86
                                           are not identified anywhere
  ASR rules              deployed          18 configured, 0 in block
  Compliance policy      compliant         no device risk requirement
  Custom detections      -                 0
  Script block logging   -                 unconfigured
  LAPS                   -                 not deployed. one password,
                                           865 machines

Every REPORTED value is accurate.

Read the left column first and then the right. Nothing in the reported column is false, nobody is misleading anybody, and an organization could pass a light-touch audit on it. The right column is the same estate described by someone who went and looked, and the two are not in conflict, because they answer different questions.

The rows with a dash in the reported column are the interesting ones. Custom detections, script block logging and LAPS do not appear on a dashboard at all, so their absence produces no red indicator anywhere. An estate does not fail to notice these; it is never presented with them, which is why the readings in ES0.3 and ES0.4 have to be run deliberately rather than watched for.

The gap between the columns also explains a conversation that recurs. Somebody senior asks whether the organization is protected, an honest person looks at the console and says the coverage is high, and both parties leave the room satisfied. Nobody lied and nobody learned anything, because the question was about the right column and the answer came from the left.

The way out of that is to stop reporting a state and start reporting a pair. Coverage of ninety per cent with zero rules enforcing is a sentence that survives being repeated to a board, and it invites the next question rather than closing it down. It also happens to be the shape of every metric in ES0.4: a deployment number is only meaningful beside a configuration number.

One caution about the right column, learned wherever anybody has built one. It has to be produced from devices rather than from policy exports, and it has to be produced on a sample large enough to catch a population rather than a machine. Reading one laptop tells you about one laptop, and the failure modes in this estate cluster by site, by image and by hardware generation. Twenty devices chosen across those three axes will find the 214 machines with cloud protection off; one device chosen because it is on your desk almost certainly will not.

Sixty-one of Northgate's 865 endpoints run Windows 10. Support for it ended on 14 October 2025, which means no operating system security updates: no kernel fixes, no driver fixes, no privilege escalation fixes. The machines still boot, still run the business, and still appear in every coverage count as protected devices.

The reason they read as protected is worth understanding precisely, because it is the same failure ES0.1 described in a new place. Microsoft continues delivering Defender definition updates to Windows 10, and has committed to doing so into 2028. The scanner therefore stays current, the console shows a healthy device with fresh signatures, and the vulnerabilities accumulating underneath it are in a layer the scanner has no opinion about. Generation one is working perfectly on an operating system nobody is fixing.

PS C:\> Get-CimInstance Win32_OperatingSystem |
            Select-Object Caption, BuildNumber, OSArchitecture

Caption                        BuildNumber OSArchitecture
-------                        ----------- --------------
Microsoft Windows 10 Pro       19045       64-bit

PS C:\> Get-MpComputerStatus | Select-Object AntivirusSignatureAge,
            AntivirusSignatureLastUpdated

AntivirusSignatureAge AntivirusSignatureLastUpdated
--------------------- -----------------------------
                    0 14/03/2026 04:12:19

Build 19045 is Windows 10 22H2, the only version eligible for extended updates at all, and the signature age is zero. A compliance rule testing whether antivirus is current passes this device. A rule testing minimum OS build would fail it, and most estates have the first rule and not the second.

The commercial extended security updates program is the bridge, and its pricing is the part that decides the argument. Year one is roughly sixty-one dollars per device and the price doubles each subsequent year, for up to three years. Entering the program late does not save money either: starting in a later year requires buying the previous ones as well, so deferral compounds rather than delays.

The teaching point is not the arithmetic, it is that this is a security decision arriving as a budget line. Some of those machines cannot run Windows 11 at all, because certain older processors lack instructions the current builds require, and no configuration resolves that. Establishing how many of the 61 are upgradeable and how many are replacements is a hardware inventory question, and it needs answering before the program is costed rather than after.

There is a third option that is frequently the right one and rarely the one presented. Some of those 61 machines are doing work that does not need a general-purpose desktop at all: a machine driving a plotter, a shared terminal in a workshop, a kiosk in reception. Moving that work to something with a smaller attack surface, or segmenting the machine so its reach is limited, costs less than either upgrading or extending and closes more risk than either. It requires knowing what each machine is for, which is a conversation with the people using it rather than a query.

Northgate has four gaps and they are usually listed by product area, which puts them in the order of who owns them rather than the order they matter. Ordering them by when an intrusion encounters each one changes the priority materially.

Hardening is met first, at execution, and it is the thinnest: ASR in audit, no LAPS, no exploit protection, no application control. Detection is met second, once something is running, and it is entirely built-in analytics with nothing written for this estate. Forensic readiness is met third, in the sense that it is not met at all and its absence is only discovered afterwards. Servers and Linux are met last and are outside most of the tooling above.

PS C:\> $p = Get-MpPreference
PS C:\> [pscustomobject]@{
            AsrBlocking = ($p.AttackSurfaceReductionRules_Actions |
                             Where-Object { $_ -eq 1 }).Count
            LapsPresent = [bool](Get-ItemProperty $lapsKey -EA 0)
            ScriptBlock = (gp $sbKey -EA 0).EnableScriptBlockLogging
        } | Format-List

AsrBlocking : 0
LapsPresent : False
ScriptBlock :

Three readings, three gaps, one machine. The first two are gap one and cost policy changes; the blank third is gap three and is the only one of them that cannot be applied retrospectively to an incident that has already happened.

It is worth being concrete about what "outside most of the tooling" means, because it is easy to read as neglect and it is usually not. Northgate's servers are onboarded and their telemetry lands in the same tables. What does not carry across is the control surface: attack surface reduction rules are a Windows client mechanism, the baselines are different, and the Linux hosts have a package manager, a service manager and an audit subsystem that none of the endpoint work in this course touches. The team that runs them is also a different team, with a change process built around uptime rather than around security posture.

That makes the fourth gap a scoping decision rather than a backlog item. Either the servers are in your remit, in which case the toolchain and the relationships need building deliberately, or they are not, in which case somebody should be able to name who owns them. The failure mode is the third answer, where everybody assumes it is covered by the endpoint program because the sensor is present.

Order the four by cost against effect and the sequence is unambiguous. Hardening is policy changes with no purchase and closes the gap met first. Detection is engineering time that continues indefinitely. Readiness is policy plus a storage bill, and it is the only one that cannot be applied retrospectively. Servers are a different toolchain and a different set of relationships. A program that runs them in that order delivers something in week one, and a program sequenced by team capacity usually starts with whichever of the four has a person free.

Read the cost lines against the order. The gap met first is the cheapest to close and the gap met last is the most expensive, which is the opposite of how most programs are sequenced, because programs get sequenced by which team has capacity rather than by where the attacker actually arrives.

Every estate rolls controls out in rings, and the rings are chosen for good reasons: start with willing volunteers, then IT, then the general population, then the awkward cases. The awkward cases are where an operator wants to be, and the correlation is not accidental.

At Northgate the awkward cases are the CAD workstations, which have a performance exception and their own baseline; Bristol, which has its own IT arrangement and joined the tenant last; the contractor laptops, enrolled but not fully managed; and the 61 Windows 10 machines, excluded from the baseline because it requires a build they cannot meet. Four populations, roughly 140 devices, each exempt from something for a reason somebody could defend.

Three of the four exemptions are not security decisions at all. The CAD exception is a performance decision, Bristol is an acquisition artifact, and the contractor laptops are a legal position about managing hardware the organization does not own. Only the Windows 10 exclusion came from a security policy, and that one was written correctly: a baseline requiring a minimum build cannot apply to machines that cannot reach it.

That matters for how you close them. An exemption created by another team's constraint is not removed by tightening a security policy; it is removed by solving that team's problem or by accepting the risk explicitly and writing it down. Attempting the first without acknowledging the second is how a security team acquires a reputation for not understanding the business, and it is avoidable by asking whose decision it was before proposing to reverse it.

So the useful artifact is not a list of exemptions but a list of owners. An exemption with a named owner and a stated condition can be reviewed; one without either can only be inherited. That list is the third line of the page this section builds toward, and the longest to produce, because it is the only one no console can answer.

The chain in ES0.2 moved from an engineering laptop to a Sales one, and Sales is exactly the population that acquires controls last on most estates. That is the sentence worth carrying: the map of your coverage gaps and the map of an operator's likely path are usually the same map, drawn by two people who have never compared them.

The fix is one field rather than a process. An exemption needs a removal condition written beside it at the moment it is created: the version the vendor has to ship, the hardware that has to be replaced, the test that has to pass. With that field, every review is a question with an answer. Without it, every review is an argument about a decision nobody present was part of, which is why the outcome is always to leave it alone.

Put the four gaps and the exempt populations together and the path writes itself. It needs no zero-day and no unusual tooling, and every step is available because of a decision that was reasonable when it was taken.

A macro-enabled attachment reaches a user, because executable content from email is an ASR rule sitting in audit. Word starts PowerShell, because that rule is in audit too. The payload runs, and the cloud verdict that might have stopped it never happens on the 214 devices where cloud protection is off. Credentials come out of memory, because the LSASS rule is auditing and Credential Guard is not enabled. The local administrator hash works on all 865 machines, because LAPS is not deployed. The operator moves to a Bristol machine, which is outside the current baseline. Afterwards nobody can reconstruct any of it, because script block logging was never configured.

Count the decisions in that paragraph. Seven steps, and each one was enabled by a choice that had a defensible reason at the time: rules left in audit pending exclusion work, cloud protection switched off for a bandwidth concern, a shared password set during imaging, a site that joined late. Nobody made a bad decision and the estate is nonetheless walked end to end by an operator who brought nothing unusual with them.

That is the argument this course rests on, and it is worth having ready in the form above rather than as a principle. A list of controls that are not enforcing reads as a compliance finding and gets prioritized against everything else on the list. The same information written as a path reads as a description of what will happen, and it gets prioritized differently by the same people.

// The estate as the fleet reports it: OS spread and quiet devices
DeviceInfo
| summarize arg_max(Timestamp, OSPlatform, OSVersion) by DeviceName
| summarize Devices = count(),
            Quiet = countif(Timestamp < ago(7d))
            by OSPlatform, OSVersion
| sort by Devices desc

Run that against your own tenant before writing anything about your estate. The second column is the one nobody expects: devices that have not reported in a week are counted in your fleet total and are absent from every hunting result, and an operating system version with a high quiet count is usually a population that fell out of management rather than a population that went home.

Everything above is a template rather than a description of somebody else's problem. The version of it for your estate is six lines, and five of them come from readings you have already met in this module.

The four counts and their gaps. The reported-against-actual table for the controls you own. The populations that are exempt from something, with the reason and the owner beside each. The four gaps ordered by when an intrusion meets them rather than by team. The lifecycle position of every operating system in the fleet, with dates. And the path, written out, from the first of those gaps to the last.

Keep it to one page and resist the temptation to make it complete. The purpose is to be read by somebody who controls budget or change approval, and the version that includes every caveat is the version that gets skimmed. Six lines with numbers in them, each traceable to a reading somebody could repeat, is more persuasive than a full assessment, and it takes an afternoon rather than a quarter.

Date it as well. Every figure in it decays: counts move as devices are bought and retired, configuration drifts, and the lifecycle dates are fixed but the fleet's position against them is not. An undated page gets quoted a year later as though it were current, which is how an organization ends up defending a number nobody has checked since.

The hardest line is the third and it is not technical. Finding which populations are exempt takes an afternoon; finding out why, and who agreed to it, means asking people about decisions that predate them, and the honest answer is frequently that nobody knows. Record that as the answer when it is true, because an exception with no owner is a different finding from an exception with a bad reason, and only one of them can be closed by an engineer.

The next section takes that page and turns it into an order of work, starting with the layer that has to exist before any of the others can be measured at all.