Anyone who has tried to teach a model to spot trouble in IT systems knows the uncomfortable truth: the model is only as good as the signals it is fed. Servers and pipelines usually get the attention, yet the laptops, phones and tablets that staff actually touch all day produce signals that rarely reach an operations team in any organised way. That gap is where EndpointOps becomes interesting for anyone working on AIOps in 2026.

The term is informal. The Ops Atlas describes it in its entry on EndpointOps as the practice of running user devices through their entire life, from enrolment to retirement, with configuration, compliance, encryption, detection-sensor health and access decisions along the way. The same entry is candid that it is not a formal discipline, only a convenient label sitting between device management and endpoint security. That honesty is useful, because it tells us we are dealing with a data-rich overlap rather than a finished product category.

Why endpoint state is a telemetry problem

Every managed device reports a small heartbeat. In the Intune example the Atlas uses, a device checks in roughly every eight hours, while a compliance verdict is treated as fresh for a month unless you change it. Those two numbers define how stale your picture of the fleet can get before a machine silently drops out of view. For anyone building anomaly detection, they are sampling intervals, and sampling intervals shape what can be detected at all.

Consider what a model would see if it consumed only the console’s headline figure. The Atlas walks through a small lab reconciliation in which the console’s tally read 8 of 9 healthy, an apparent 89%. When the lab compared the console against a second and third list, the share that was fully managed, compliant, encrypted and running a healthy detection sensor dropped to four of ten, or 40 percent. A trend model trained on the first number would see a calm, flat line. The second number describes the actual situation.

The three-source habit

The Atlas recommends comparing three independent lists: what the management console believes, what the security sensor reports, and what the identity or procurement side says should exist. Disagreement between them is the signal. A device present in procurement but absent from the console is an unmanaged machine. A device in the console with no sensor heartbeat for seven days, the inactivity threshold the Atlas cites for Defender, is a blind spot. A device silent past the thirty-day validity window is treated as noncompliant, which is a rule a pipeline can encode in a single line.

This is the kind of feature engineering AIOps teams already enjoy elsewhere. Our own notes on cutting event noise with smarter tooling argue that fewer, better-correlated events beat a flood of raw alerts. Endpoint data suits that philosophy: a handful of reconciled counts is far more informative than thousands of per-device status messages.

Traps that corrupt the data

A few default behaviours in device platforms quietly pollute the numbers, and the Atlas flags them. The most striking is a tenant setting that decides how to label devices with no compliance policy assigned. By default those devices are marked compliant. A fleet can therefore look healthy simply because nobody wrote a policy for part of it, and Microsoft’s own guidance, as reported in the Atlas, is to switch that default to not compliant wherever conditional access depends on the result.

A second trap is timing. A disk-encryption check measured at boot means a freshly encrypted machine stays noncompliant until it restarts, while a looser setting only checks that some form of encryption exists. A detector that treats both as the same event will raise false alarms or miss real gaps. The lesson for modelling is to record which setting produced a status, not just the status itself.

A third trap is housekeeping. Deleting stale device records feels tidy, but the Atlas warns that removing the record for a joined device can suspend its disk encryption and destroy recovery keys. Activity timestamps refresh only about every fourteen days, so a device inactive for under twenty-one days is not truly stale. Any automated cleanup that an AIOps platform proposes should respect that window.

What the 2024 outage taught observers

The Atlas revisits the July 2024 incident in which a bad content update knocked out about 8.5 million Windows computers, going by Microsoft’s own count. Recovery in many cases demanded recovery keys for encrypted disks, and roughly 99 percent of sensors were back about ten days later. From an observability angle, the interesting part is how long the fleet-level picture lagged behind reality, and how much depended on whether keys had been stored somewhere retrievable before the day they were needed.

The Atlas also records a March 2026 incident at a medical-device maker, where a global disruption to the company’s Microsoft environment was followed by a CISA alert urging narrow admin roles, stronger sign-in methods and a second approver on bulk wipes. Press accounts of the mechanism remain unverified by the companies, so hold the details loosely. The takeaway for monitoring is simple: administrative actions on the device plane deserve their own anomaly baselines. A sudden burst of wipe or retire commands is as alarming as any latency spike.

Metrics worth putting on a dashboard

The Atlas floats six fleet indicators for a dashboard. Reach is counted by who has checked in during a rolling month. Watchfulness is counted by sensors that spoke up within a week. Recoverability is counted by escrowed keys among encrypted disks. The remaining three are how much sign-in activity comes from unmanaged hardware, how many machines still run a vendor-supported release, and the stopwatch time for fetching a key on request. Its worked example of escrow is 1,164 encrypted machines with 1,131 escrowed out of 1,200 in total, which works out to 94.3 percent. Each of these is a ratio with a clear numerator and denominator, which makes them well suited to trend and drift detection.

• Coverage ratios change slowly, so a sudden step is meaningful.
• Sensor health is bounded by a hard window, so it works as a threshold alert.
• Escrow percentage should only move up, so any dip suggests a process fault.
• Key retrieval time is a drill result, something to time on a schedule rather than during a crisis.

Where this leaves AIOps teams

The practical message is modest. Before reaching for sophisticated models, make sure the endpoint data feeding them is reconciled, timestamped by source and free of misleading defaults. If you are still shaping how your own organisation adopts automation, our walkthrough on bringing AIOps to your IT group is a reasonable companion, because the same sequencing applies: clean inputs first, cleverness second.

EndpointOps will probably remain an informal name. Its value is as a checklist of questions about devices that every operations group should be able to answer: which machines exist, which are governed, which are healthy, and who can change them. Teams that can answer those with numbers are better placed to apply any analytics on top.