EndpointOps

EndpointOps (endpoint operations) is the work of running user devices (laptops, desktops, phones and tablets) through their whole life: enrolling, configuring and hardening them, proving they are compliant, encrypting them, keeping their endpoint detection and response (EDR) agents healthy, letting only healthy devices reach company data, and retiring them safely. It sits where IT device management meets security: the console that installs an app also decides whether the device may open email. The label is rare; practitioners say endpoint management, unified endpoint management (UEM), mobile device management (MDM) and endpoint security.

In one line: every device that touches company data is known, configured, encrypted, monitored and recoverable, and access depends on it.

For beginners, endpoint and security engineers, architects, and leaders deciding how much to control devices people carry home.

NIST defines an endpoint as “Any device that is used to access a digital identity on a network, such as laptops, desktops, mobile phones, tablets, servers, Internet of Things devices, and virtual environments”.^[1] This page narrows that to the devices people use. Three things go wrong when nobody owns them as a system:

1. Unknown devices. Control 1 of the Center for Internet Security (CIS) asks organisations to “Actively manage (inventory, track, and correct) all enterprise assets”, partly to support “identifying unauthorized and unmanaged assets to remove or remediate”.^[2] A laptop that reads email but was never enrolled is invisible to every control on this page.
2. Management and security drift apart. One team owns the management console, another owns EDR, and each misses devices the other sees. CISA’s Zero Trust Maturity Model 2.0 describes, at its most mature stage, “a unified approach for device threat protection, policy enforcement, and compliance monitoring”.^[3]
3. Access ignores device state. NIST’s zero trust architecture says: “The enterprise monitors and measures the integrity and security posture of all owned and associated assets. No asset is inherently trusted.”^[4]

• Not a defined discipline. No standards body or professional community defines “EndpointOps”. Its most visible use is a product: Zirozen’s Trinetri platform has a module named EndpointOps, “a unified endpoint management platform”.^[5] A PowerShell toolkit for SentinelOne and CyberArk Endpoint Privilege Manager also names its module EndpointOps.^[6] This page is about neither.
• Not alert triage or incident response. EndpointOps keeps EDR deployed and healthy; alerts belong to SOC Ops, detections to DetectionOps, intrusions to ResponseOps.
• Not patching. Rings and patch compliance belong to PatchOps, fix priorities to VulnerabilityOps. This page owns whether an out-of-date device may still reach data.
• Not identity. Accounts, single sign-on and multi-factor authentication (MFA) belong to IdentityOps, elevation to AccessOps; this page supplies the device signal.
• Not servers, IoT or app releases: SysOps, IoTOps and MobileOps.

Management. PCs had client management tools and smartphones MDM; enterprise mobility management (EMM) suites added app management,^[7] and the combined category became unified endpoint management.^[8] Operating systems built management in: Windows ships “A built-in management component” for MDM servers,^[9] and Apple’s Automated Device Enrolment (ADE) manages devices “from the moment someone removes a device from its box”.^[10] In March 2026 Apple announced that Apple Business, with built-in device management, would replace Apple Business Manager from 14 April 2026; Apple’s deployment guide (September 2026) now refers to Apple Business.^[11][10]

Security. In July 2013 Gartner analyst Anton Chuvakin settled on “Endpoint Threat Detection & Response” as the name for tools that detect and investigate suspicious activity on hosts;^[12] the shorter “EDR” stuck.

Convergence. Zero trust made device posture an input to access (NIST SP 800-207, 2020).^[4] CISA’s maturity model 2.0 (April 2023) points agencies to OMB memorandum M-22-01 on EDR.^[3][13] Intune’s endpoint security node gives “security admins a central location”.^[14] A faulty EDR update in 2024 and a console attack in 2026 moved attention to recovery and the management plane (Use cases).

Mental model: four records and one loop. Each device appears in the inventory (what was bought), the management service (desired and reported state), the EDR service (behaviour) and the identity provider (sign-ins). EndpointOps keeps them in agreement and runs one loop: state → compliance → access decision → fix → state. The management plane (consoles, roles and APIs) sits above the loop and is guarded like a domain controller: whoever holds it controls every device.

flowchart TB
  SE["SecOps"]:::neutral -->|baselines| E
  VU["VulnerabilityOps"]:::neutral -->|"fix priorities"| E
  PR["PrivacyOps"]:::neutral -->|"BYOD terms"| E
  E["EndpointOps: the managed device"]:::core
  E -->|"compliance signal"| ID["IdentityOps"]:::neutral
  E -->|"update rollout"| PA["PatchOps"]:::neutral
  E -->|"EDR alerts"| SOC["SOC Ops"]:::neutral
  E -->|elevation| AC["AccessOps"]:::neutral
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029

Charter (this Atlas’s proposal, not a published standard): the goal in At a glance, with access depending on it.

1. Enrol before access. A password alone does not earn access; an enrolled device or a protected app does.
2. Compliance must gate something, with a grace period; a report nobody acts on is decoration.
3. Escrow before encrypt. No disk is encrypted until the service desk can retrieve its key; macOS 26.4 and later turn FileVault on in Setup Assistant by default (as of October 2026), so the management service must hold setup until the key is escrowed.^[24]
4. Installed is not healthy. Measure check-ins, not installation counts.
5. Reconcile; do not trust one console.
6. Audit, then enforce application control, attack-surface rules and new compliance rules.
7. Guard the management plane: scoped roles, phishing-resistant sign-in, a second approver for destructive actions.
8. Personal devices get a written contract: what IT can see, erase, and never touch.

Non-goals: triaging alerts, running the patch programme, owning identities, deciding legal grounds for personal data.

Linux desktops and ChromeOS (as of October 2026). Intune enrols Ubuntu Desktop 24.04 or 26.04 LTS and Red Hat Enterprise Linux 9 or 10 through the Microsoft Intune app and evaluates compliance from settings-catalog rules: allowed distributions, dm-crypt (LUKS) disk encryption, password policy and custom compliance scripts; the compliant-device grant accepts Ubuntu.^[36][26] ChromeOS devices are enrolled and managed in the Google Admin console; the Chrome Enterprise connector syncs them into Intune’s inventory and allows deprovision, restart, lost mode and wipe, nothing more.^[37] Zero-touch and EDR coverage differ per platform, so the device standard must say which controls apply (Lab 1 expects EDR on Linux and none on ChromeOS).

R = responsible, A = accountable, C = consulted, I = informed.

stateDiagram-v2
  state "Procured" as Pro
  state "Registered for zero-touch" as Reg
  state "Enrolled and configured" as Enr
  state "Compliant, in use" as Ok
  state "Noncompliant, in grace" as Gr
  state "Blocked from data" as Blk
  state "Lost or stolen" as Lost
  state "Retired or wiped" as Ret
  state "Sanitised and disposed" as Disp
  [*] --> Pro
  Pro --> Reg: serial linked to tenant
  Reg --> Enr: first boot, user signs in
  Enr --> Ok: policies evaluated
  Ok --> Gr: a rule fails (drift)
  Gr --> Ok: fixed
  Gr --> Blk: grace ends
  Ok --> Blk: silent past validity period
  Blk --> Ok: fixed
  Ok --> Lost: reported missing
  Lost --> Ret: lock, then wipe
  Ok --> Ret: leaver or refresh
  Ret --> Reg: reset for reuse
  Ret --> Disp: end of life
  Disp --> [*]

CISA’s model says the device lifecycle “includes procuring, configuring, tracking, monitoring, updating, using, sanitizing, deprovisioning, and recovering devices”.^[3]

• Day 0: the device standard (Reference implementation), purchase channels that register serials, personal-device modes.
• Day 1: zero-touch enrolment applies configuration, escrowed encryption, EDR and apps; Autopilot turns the preinstalled Windows into a “business-ready” state instead of reimaging.^[15]
• Day 2: compliance, drift, sensor health, reconciliation, exceptions, lost devices, OS lifecycle (Windows 10 support ended on 14 October 2025^[38]).
• Retire: wipe or retire, delete records carefully (some deletions destroy recovery keys), sanitise media: NIST SP 800-88 Rev. 2 (2025) defines sanitisation as “a process that renders access to target data on the media infeasible for a given level of effort”.^[39]

Policy changes are production changes. A policy reaches every device in scope within hours, so roll it out in rings (IT, pilot, broad) as PatchOps does, through ITOps change control; agent content updates are governed in SecOps.

Protect the management plane. Microsoft’s March 2026 guidance says privileged roles such as Global Administrator and Intune Administrator “should be limited and not used for daily administrative tasks”, and recommends scope tags, time-bound elevation through Privileged Identity Management (PIM), a second approver for high-impact changes, phishing-resistant sign-in and a compliant device for admin portals, and privileged admin workstations.^[40]

flowchart TB
  ADM["Admins: scoped, time-bound roles; second approver"]:::risk --> UEM
  ZT["Zero-touch: Autopilot, Apple Business, Android"]:::neutral --> UEM
  UEM["UEM service: policies, inventory, remote actions"]:::core
  UEM <-->|"policy, check-in"| DEV["Device: OS, management client, EDR sensor"]:::core
  DEV -->|telemetry| EDR["EDR service: detections, risk level"]:::core
  EDR -->|"risk level"| UEM
  DEV -->|"recovery key, LAPS"| DIR["Directory: device objects, keys"]:::neutral
  UEM -->|"compliance flag"| IDP["Identity provider: access policy"]:::core
  DEV -->|"sign-in"| IDP
  IDP -->|"token or block"| APP["Company apps and data"]:::neutral
  EDR -->|alerts| SOC["SIEM and SOC"]:::neutral
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029

Alternatives: per-platform tools, or app-only management, if the Lab 1 reconciliation covers every source.

flowchart TB
  A["Device checks in, about every 8 hours"]:::core --> B{"Meets every compliance rule?"}:::decision
  B -->|yes| C["Compliant"]:::core
  C --> D["Sign-in: access policy sees compliant"]:::core
  D --> E["Access granted"]:::core
  B -->|no| F{"Grace period set?"}:::decision
  F -->|yes| G["In grace: user notified, access kept"]:::neutral
  G --> H{"Fixed in time?"}:::decision
  H -->|yes| C
  H -->|no| I["Noncompliant: access blocked"]:::risk
  F -->|no| I
  I --> J["User or service desk fixes"]:::neutral
  J --> A
  K["No check-in within the validity period"]:::risk --> I
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029

Happy path (Intune and Entra, as of October 2026). Devices check in “about every 8 hours”;^[43] Windows devices also request re-evaluation when key settings change (firewall, antivirus, BitLocker, Defender status, OS build, real-time protection, Secure Boot), and Intune throttles repeated re-evaluations.^[44] Microsoft announced this client-driven evaluation in September 2026.^[45] An access policy with “Require device to be marked as compliant” grants or blocks.^[17]

Exception path. Every policy’s Mark device noncompliant action is “set to zero (0) days”; changing it creates the grace period, in 0.25-day steps. Other actions notify, lock or list devices for retirement, which still needs an administrator.^[46] A device silent beyond the “Compliance status validity period” (30 days by default) is treated as noncompliant.^[47]

EDR joins the loop when a Windows compliance rule requires the device “to be at or under the machine risk score” from Defender for Endpoint: an infected device loses access until cleaned.^[44]

Defender for Endpoint considers a device inactive when it “isn’t sending any signals … for more than seven days”, and misconfigured when communications or sensor data are impaired.^[48] Tamper protection “helps protect important security settings from being disabled or changed”.^[49]

Here the baselines that SecOps chooses become settings on user devices.

1. Desired state as code. Intune’s settings catalog “lists all the settings you can configure” for Windows, Apple and Android devices.^[50] Export policies to version control, review changes like code, and tie each setting to a control ID. In Microsoft Graph these policies are beta APIs (as of October 2026), “subject to more frequent change”.^[50]
2. Layer, with one owner per setting. Vendor baseline, then a benchmark (CIS Benchmarks;^[34] mSCP for macOS^[35]), then exceptions approved by SecOps. Separate baselines “might include the same settings and use different default values”.^[33] Intune shows conflicts between configuration policies and says “Manually resolve these conflicts”; for conflicting custom Apple profiles “Apple randomly applies the settings”.^[43] So each setting gets one owning policy.
3. Find drift. Review the per-policy reports for errors and conflicts weekly;^[43] compliance rules catch drift in what gates access; Windows Remediations (paired detection and fix scripts; Windows Enterprise, Education or Virtual Desktop Access licences) repair the rest.^[51]
4. Roll out in rings, as for any policy change (Operating model).

Application control and attack-surface reduction (ASR) rules break business software when switched on blind.

1. Audit. Microsoft recommends audit mode for ASR rules, which does not affect users, starting with a first ring.^[54] Prefer App Control for Business: customers able to use it “should do so”, while AppLocker “isn’t getting new feature improvements”.^[30] On macOS, Google stopped maintaining Santa in 2025 and points to the North Pole Security fork.^[31]
2. Build rules from audit data by publisher, not path (NIST SP 800-167 covers planning).^[55]
3. Enforce in rings with a named rollback; run exceptions with expiry dates (Templates).

Why it matters: a 2023 CISA, NSA and MS-ISAC advisory described attackers running remote monitoring and management (RMM) tools as portable executables and advised that application controls “should prevent both installation and execution of portable versions of unauthorized RMM software”.^[56]

NIST SP 800-124 Rev. 2 (2023) covers mobile devices across “deployment, use and disposal”;^[7] SP 1800-22 (2023) is the BYOD practice guide and names the employer’s “degree of access to their personal devices” as a privacy risk;^[57] SP 800-111 (2007) and SP 800-167 (2015) are the older basics of storage encryption and allow-listing.^[58][55] For hardening, CIS Benchmarks and vendor baselines: Intune’s defaults are “the most restrictive” in almost all scenarios.^[34][33] CISA’s zero trust maturity model, CIS Control 1, NIST SP 800-207, SP 800-88 Rev. 2 and the mSCP are cited where used. None is mandatory by itself; contracts, sector rules or regulators make them so.

Product facts as of October 2026.

Lock-in. Policies and enrolment profiles do not move between vendors: keep the device standard tool-neutral and export policies as code.

Automate what is reversible and frequent: enrolment, compliance, notifications, reconciliation, key rotation after use. Keep a second approver on what is destructive: Intune’s Multi Admin Approval (MAA) covers wipe, retire and delete actions, scripts, apps, compliance and configuration policies, role changes and device categories, in the console and for app-authenticated Graph calls; nobody approves their own request.^[65]

MAA is only as strong as its approver group. Three documented conditions decide whether it works at all:^[65]

1. The group is a security group: distribution lists, Microsoft 365 groups and mail-enabled security groups “silently fail to resolve approver membership”.
2. The group is assigned as a member group to an Intune role; otherwise “approver group members are removed from the group periodically”.
3. Approvers are direct members; nested memberships “may result in unreliable behavior”.

Then protect the membership. Intune Administrators can change the members of security groups, Groups and User Administrators of any ordinary group, and Global Administrators of every group. So use a role-assignable group, whose membership ordinary group permissions cannot change^[66] (test that Intune accepts it as a role member group); alert on changes to it and on new Global Administrator assignments; and exclude no applications from device actions, since excluded apps “can modify protected resources without going through the approval workflow”.^[65]

MAA does not stop an attacker who already holds Global Administrator. Intune’s daily tenant caps (500 wipes, 1,000 retires, 1,000 deletes as of October 2026; changed only through Microsoft support) are a backstop, not a control: 500 wipes is about 42% of a 1,200-laptop fleet in one day.^[67]

AI agents for remediation and change review are in preview in Intune (as of October 2026);^[45] treat their output as proposals and evaluate them as AIOps for Security describes.

Assumptions: about 1,200 corporate Windows and macOS laptops, Intune and Entra ID, an EDR product. The standard comes first, tool-neutral and versioned like code.

Example status: syntax-checked (YAML parsed), not executed; a template, not a tool’s file format.

# device-standard.yaml: what "compliant" means, before any tool is chosen
standard: corporate-laptops
version: "2026-10"
owner: endpoint-engineering
approvers: [security-engineering, identity-team]
scope:
  ownership: corporate
  platforms: [windows, macos]
controls:
  - id: ENR-01
    rule: Enrolled by zero-touch; user cannot remove management
    evidence: management record showing the enrolment type
  - id: ENC-01
    rule: OS volume encrypted; recovery key escrowed before encryption starts
    evidence: encryption report plus key present in the directory
    grace_hours: 72
  - id: EDR-01
    rule: EDR sensor active, tamper protection on, seen within 7 days
    evidence: weekly three-source reconciliation
  - id: OS-01
    rule: OS release still in vendor security support
    evidence: compliance minimum-version rule
    grace_hours: 336
  - id: ADM-01
    rule: User is a standard user; local admin password managed by LAPS
    evidence: local administrators report and LAPS backup time
  - id: CFG-01
    rule: Approved hardening baseline applied; each setting owned by one policy
    evidence: configuration report with no errors or conflicts
access:
  noncompliant_after_grace: block
  no_policy_assigned: noncompliant
  check_in_validity_days: 30
admin_plane:
  destructive_actions: second approver from a role-assignable group
  approver_group: security group, assigned to an Intune role, direct members only
  standing_global_admins: break-glass accounts only
exceptions:
  max_days: 90
  approver: security-engineering

The Windows part of ENC-01 and OS-01, expressed as a Microsoft Graph windows10CompliancePolicy. Property names are from the v1.0 resource;^[68] Graph requires exactly one block scheduled action per policy, with ruleName fixed to PasswordRequired, and gracePeriodHours sets the delay.^[68] This page assumes block is the API form of the portal’s Mark device noncompliant; confirm by reading the policy back in the admin centre.

Example status: JSON syntax-checked, not executed (requires an Intune tenant). Replace the placeholder version.

{
  "@odata.type": "#microsoft.graph.windows10CompliancePolicy",
  "displayName": "WIN-LAPTOP-STD-2026-10",
  "description": "Device standard 2026-10: ENC-01, OS-01, Secure Boot",
  "bitLockerEnabled": true,
  "secureBootEnabled": true,
  "codeIntegrityEnabled": true,
  "osMinimumVersion": "REPLACE_WITH_MINIMUM_SUPPORTED_BUILD",
  "scheduledActionsForRule": [
    {
      "ruleName": "PasswordRequired",
      "scheduledActionConfigurations": [
        { "actionType": "block", "gracePeriodHours": 72 }
      ]
    }
  ]
}

The access side, created in report-only mode first. Property values are from the Graph resources;^[69] the policy is limited to Windows because report-only policies that require a compliant device “can prompt users on macOS, iOS, and Android devices” to select a certificate.^[70]

Example status: JSON syntax-checked, not executed. Replace the two object IDs.

{
  "displayName": "PILOT report-only: Windows requires compliant device",
  "state": "enabledForReportingButNotEnforced",
  "conditions": {
    "clientAppTypes": ["all"],
    "applications": { "includeApplications": ["All"] },
    "users": {
      "includeGroups": ["<pilot-group-object-id>"],
      "excludeUsers": ["<break-glass-account-object-id>"]
    },
    "platforms": { "includePlatforms": ["windows"] }
  },
  "grantControls": { "operator": "OR", "builtInControls": ["compliantDevice"] }
}

Settings that complete the design: no-policy devices marked Not compliant; BitLocker keys stored in Entra ID before encryption, with recovery password rotation;^[28] LAPS;^[23] Multi Admin Approval with a protected approver group;^[65] emergency access accounts excluded from access policies.^[17]

Objective: find devices one system knows and another does not, and compute coverage honestly. Prerequisites: Python 3.8+; 20 minutes; optionally real UEM, EDR and identity-provider exports with a serial column. Cost and risk: none (read-only); real exports hold personal data, so keep them encrypted.

1. Save the three sample files below as uem.csv, edr.csv and idp.csv, and the script as reconcile.py.
2. Run python3 reconcile.py --as-of 2026-10-16.
3. For each exception, write down an owner and a next action.
4. Replace the samples with real exports (rename columns to match) and run without --as-of.

uem.csv
serial,device_name,owner,platform,compliance,encrypted,last_sync
PF3A1001,LT-ANA,ana@example.com,windows,compliant,true,2026-10-15
PF3A1002,LT-BEN,ben@example.com,windows,compliant,true,2026-10-16
C02X1003,MB-CHO,cho@example.com,macos,compliant,true,2026-10-14
PF3A1004,LT-DEV,dev@example.com,windows,noncompliant,false,2026-10-16
PF3A1005,LT-EVA,eva@example.com,windows,compliant,true,2026-08-30
PF3A1008,LT-HAL,hal@example.com,windows,compliant,true,2026-10-13
PF3A1009,LT-OLD,ivy@example.com,windows,compliant,true,2026-06-18
PF3A1010,LT-JON,jon@example.com,windows,compliant,true,2026-10-16
F2LX1011,PH-KAI,kai@example.com,ios,compliant,true,2026-10-16

edr.csv
serial,hostname,sensor_status,last_seen
PF3A1001,LT-ANA,active,2026-10-16
PF3A1002,LT-BEN,active,2026-10-16
C02X1003,MB-CHO,misconfigured,2026-10-16
PF3A1004,LT-DEV-OLD,inactive,2026-07-02
PF3A1004,LT-DEV,active,2026-10-16
PF3A1005,LT-EVA,active,2026-10-14
PF3A1007,CTR-LAP-07,active,2026-10-15
PF3A1009,LT-OLD,inactive,2026-06-20
 pf3a1010 ,LT-JON,active,2026-10-16

idp.csv
serial,display_name,trust_type,last_sign_in
PF3A1001,LT-ANA,joined,2026-10-09
PF3A1002,LT-BEN,joined,2026-10-02
C02X1003,MB-CHO,registered,2026-10-11
PF3A1004,LT-DEV,joined,2026-10-12
PF3A1005,LT-EVA,joined,2026-10-06
PF3A1006,HOME-PC,registered,2026-10-08
PF3A1008,LT-HAL,joined,2026-10-01
PF3A1009,LT-OLD,joined,2026-06-19
PF3A1010,LT-JON,joined,2026-10-07
F2LX1011,PH-KAI,registered,2026-10-10
,VM-TEMP,registered,2026-10-15

Example status: verified by execution (Python 3.8.10, 2026-10-17) with the sample files above, and with a reordered duplicate, an empty export and timestamped dates.

#!/usr/bin/env python3
"""Reconcile device exports from UEM, EDR and the identity provider (IdP).

Read-only: reads three CSV files and prints coverage KPIs and exceptions.
Thresholds follow the vendor defaults discussed on the EndpointOps page:
UEM check-in older than 30 days, EDR silent for more than 7 days, and
IdP activity within 30 days counted as "in use".
"""
import argparse
import csv
from datetime import date

EDR_EXPECTED = {"windows", "macos", "linux"}  # phones: mobile threat defence instead
WARNINGS = []


def norm(serial):
    return (serial or "").strip().upper()


def day(value):
    return date.fromisoformat(value.strip()[:10])  # accepts dates and timestamps


def load(path, stamp):
    """Return {serial: row}; skip blank serials, keep the newest duplicate."""
    rows = {}
    with open(path, newline="", encoding="utf-8") as fh:
        for r in csv.DictReader(fh):
            s = norm(r["serial"])
            if not s:
                WARNINGS.append(f"{path}: row without serial skipped")
                continue
            if s in rows:
                WARNINGS.append(f"{path}: duplicate {s}, newest row kept")
                if day(r[stamp]) <= day(rows[s][stamp]):
                    continue
            rows[s] = r
    return rows


def main():
    p = argparse.ArgumentParser()
    p.add_argument("--uem", default="uem.csv")
    p.add_argument("--edr", default="edr.csv")
    p.add_argument("--idp", default="idp.csv")
    p.add_argument("--as-of", default=date.today().isoformat())
    a = p.parse_args()
    as_of = date.fromisoformat(a.as_of)
    uem = load(a.uem, "last_sync")
    edr = load(a.edr, "last_seen")
    idp = load(a.idp, "last_sign_in")

    def age(row, col):
        return (as_of - day(row[col])).days

    fresh_uem = {s for s, r in uem.items() if age(r, "last_sync") <= 30}
    live_edr = {s for s, r in edr.items() if age(r, "last_seen") <= 7}
    used_idp = {s for s, r in idp.items() if age(r, "last_sign_in") <= 30}
    active = fresh_uem | live_edr | used_idp
    retired = sorted((set(uem) | set(edr) | set(idp)) - active)

    def platform(s):
        return uem[s]["platform"] if s in uem else "unknown"

    healthy_edr = {s for s in live_edr if edr[s]["sensor_status"] == "active"}
    needs_edr = {s for s in active if platform(s) in EDR_EXPECTED or s not in uem}
    managed = active & fresh_uem
    compliant = {s for s in managed if uem[s]["compliance"] == "compliant"}
    encrypted = {s for s in managed if uem[s]["encrypted"] == "true"}
    edr_ok = {s for s in active if s not in needs_edr or s in healthy_edr}
    assured = compliant & encrypted & edr_ok

    def pct(part, whole):
        if not whole:
            return "0/0 (empty set: check the export)"
        return f"{len(part)}/{len(whole)} = {100 * len(part) / len(whole):.0f}%"

    print(f"As of {as_of}: {len(active)} active devices, "
          f"{len(retired)} cleanup candidates")
    print("Management coverage (UEM check-in <= 30 d):", pct(managed, active))
    print("EDR coverage (healthy sensor, where required):",
          pct(needs_edr & healthy_edr, needs_edr))
    print("Encryption (of managed):", pct(encrypted, managed))
    print("Fully assured (managed, compliant, encrypted, EDR ok):",
          pct(assured, active))
    print("\nExceptions:")
    for s in sorted(used_idp - set(uem)):
        print(f"  {s} signing in but not managed "
              f"({idp[s]['display_name']}, {idp[s]['trust_type']})")
    for s in sorted(live_edr - set(uem)):
        print(f"  {s} EDR only, no UEM record ({edr[s]['hostname']})")
    for s in sorted(active & set(uem) - fresh_uem):
        print(f"  {s} UEM check-in stale: {age(uem[s], 'last_sync')} days")
    for s in sorted((needs_edr & managed) - healthy_edr):
        state = edr[s]["sensor_status"] if s in edr else "no sensor"
        print(f"  {s} EDR not healthy: {state}")
    for s in sorted(managed - compliant):
        print(f"  {s} noncompliant (encrypted={uem[s]['encrypted']})")
    for s in retired:
        print(f"  {s} no activity anywhere for 30+ days: review, then retire")
    if WARNINGS:
        print("\nData warnings:")
        for w in WARNINGS:
            print(f"  {w}")


if __name__ == "__main__":
    main()

Expected output (exactly as produced on 2026-10-17):

As of 2026-10-16: 10 active devices, 1 cleanup candidates
Management coverage (UEM check-in <= 30 d): 7/10 = 70%
EDR coverage (healthy sensor, where required): 6/9 = 67%
Encryption (of managed): 6/7 = 86%
Fully assured (managed, compliant, encrypted, EDR ok): 4/10 = 40%

Exceptions:
  PF3A1006 signing in but not managed (HOME-PC, registered)
  PF3A1007 EDR only, no UEM record (CTR-LAP-07)
  PF3A1005 UEM check-in stale: 47 days
  C02X1003 EDR not healthy: misconfigured
  PF3A1008 EDR not healthy: no sensor
  PF3A1004 noncompliant (encrypted=false)
  PF3A1009 no activity anywhere for 30+ days: review, then retire

Data warnings:
  edr.csv: duplicate PF3A1004, newest row kept
  idp.csv: row without serial skipped

Validation. By hand: ten serials are active somewhere, and only four (1001, 1002, 1010 and phone 1011) pass every test, while the console alone shows 8 of 9 compliant. Troubleshooting: KeyError means a column name differs. Re-enrolled devices appear twice; the script keeps the newest record and warns. If nothing matches, one tool exports hostnames: join on the directory device ID (Intune’s azureADDeviceId^[71]); VMs and replaced boards can change serials. Teardown: delete real exports.

Objective: measure how far the console lags the device. Prerequisites: an enrolled test Windows device, local admin rights, optionally osquery;^[63] 45 minutes. Cost and risk: read-only, except the reboot in step 4.

Example status: not executed (no test device in this environment); cmdlets and tables checked against vendor documentation and osquery’s table specifications.^[72][73]

# Elevated PowerShell on a TEST device. Read-only.
manage-bde -status C:
Get-BitLockerVolume -MountPoint C: |
  Select-Object MountPoint, VolumeStatus, ProtectionStatus, KeyProtector
# Defender Antivirus state; EDR sensor health is read in the EDR console
Get-MpComputerStatus |
  Select-Object AMRunningMode, RealTimeProtectionEnabled, AntivirusSignatureAge
dsregcmd /status | Select-String 'AzureAdJoined', 'DomainJoined', 'WorkplaceJoined'

-- osqueryi: the same questions on any platform
SELECT name, version, platform FROM os_version;
SELECT hardware_serial, hardware_model FROM system_info;
-- Windows
SELECT drive_letter, protection_status, percentage_encrypted FROM bitlocker_info;
-- macOS, Linux
SELECT name, encrypted, encryption_status FROM disk_encryption;
-- Windows
SELECT antivirus, firewall, autoupdate FROM windows_security_center;

1. Run the local checks and record the results with the time.
2. In the admin centre, record compliance state, encryption state and last check-in.
3. Sync from the Company Portal app (Settings > Sync)^[43] and time the console update.
4. If encryption finished recently but the device shows noncompliant, reboot: Require BitLocker is measured at boot.^[44]

Expected output: local and console values agree after a sync. Validation: you can name each control’s source of truth and its lag. Troubleshooting: if AzureAdJoined and WorkplaceJoined are both NO, the device has no Entra identity and cannot satisfy a compliant-device policy;^[26] an empty bitlocker_info usually means osquery is not elevated. Teardown: uninstall osquery if added.

Objective: connect compliance to access without blocking anyone. Prerequisites: a test tenant with Intune and Entra ID P1 (Conditional Access “requires Microsoft Entra ID P1 licenses”^[74]); two test Windows devices, one unencrypted; a pilot group; an emergency access account; Microsoft Graph PowerShell; an admin holding Conditional Access Administrator (or Security Administrator) and an Intune role such as Policy and Profile Manager;^[75] 2 hours. Cost and risk: trial licences; a wrong access policy can lock admins out, hence report-only, a break-glass exclusion and Windows only.

Example status: not executed (requires an Intune test tenant); endpoints and permissions checked against Microsoft Graph documentation.^[75]

# TEST tenant only. Creates one compliance policy and one report-only access policy.
# -ContextScope Process: the token is not cached for later PowerShell sessions.
$scopes = @("DeviceManagementConfiguration.ReadWrite.All",
  "Policy.Read.All", "Policy.ReadWrite.ConditionalAccess")
Connect-MgGraph -ContextScope Process -Scopes $scopes
$g = "https://graph.microsoft.com/v1.0"
$cp = Invoke-MgGraphRequest -Method POST `
  -Uri "$g/deviceManagement/deviceCompliancePolicies" `
  -Body (Get-Content ./win-compliance.json -Raw) -ContentType "application/json"
$ca = Invoke-MgGraphRequest -Method POST `
  -Uri "$g/identity/conditionalAccess/policies" `
  -Body (Get-Content ./ca-report-only.json -Raw) -ContentType "application/json"
"compliance policy: $($cp.id)   access policy: $($ca.id)"   # keep both for teardown

1. In the test tenant set Mark devices with no compliance policy assigned as to Not compliant.
2. Save the two JSON documents from the reference implementation as win-compliance.json and ca-report-only.json; fill in the IDs and minimum build, and set gracePeriodHours to 0 for the lab (72 hours would delay the result by three days).^[46]
3. Run the PowerShell block, then assign the compliance policy to the pilot device group in the admin centre.
4. After both devices check in, sign in from each and open the sign-in log’s Report-only tab.

Expected output: “Report-only: Success” for the encrypted device, “Report-only: Failure” for the other; nobody blocked.^[70] Validation: results match compliance states. Troubleshooting: all fail → not yet evaluated (wait, or reboot after encryption); “Not applied” → wrong group or platform; HTTP 403 → missing scopes or roles; an approval-required error → a Multi Admin Approval policy covers compliance policies.^[75] Teardown (then revert step 1 if the tenant is shared):

$g = "https://graph.microsoft.com/v1.0"
Invoke-MgGraphRequest -Method DELETE `
  -Uri "$g/identity/conditionalAccess/policies/<access-policy-id>"
Invoke-MgGraphRequest -Method DELETE `
  -Uri "$g/deviceManagement/deviceCompliancePolicies/<policy-id>"
Disconnect-MgGraph

In production, keep report-only for at least a business week, review, then set state to enabled for the pilot before widening.

1. Recovering encrypted laptops after a bad agent update (sourced). On 19 July 2024 a CrowdStrike content update crashed Windows machines; Microsoft estimated it “affected 8.5 million Windows devices”.^[76] Microsoft warned “You may be asked to enter your BitLocker recovery key” and told users to “use your phone” to fetch it.^[77] Its recovery tool offered Windows Preinstallation Environment (WinPE) media, which may need the key, or safe-mode media, which needs “an account with local administrator rights” and avoids the key only with TPM-only protectors.^[22] CrowdStrike reported about 99% of Windows sensors back online by 29 July.^[42] Lesson: keys and local admin passwords are recovery tools: escrowed, retrievable from a second device, audited, rotated after use. Success metric: escrowed-key share; minutes to retrieve a key.

2. The management plane as the attack path (sourced; details partly from press reports). On 11 March 2026 an attack caused “a global disruption to Stryker’s Microsoft environment”.^[78] CISA’s alert of 18 March, with contributions from Microsoft and Stryker, urged organisations to “harden endpoint management system configurations”: least-privilege roles, phishing-resistant MFA, and a second administrator’s approval for “sensitive or high-impact actions (such as device wiping)”.^[41] Stryker’s page does not describe the attack path.^[78] BleepingComputer, citing one unnamed source, reports that the attackers used a new Global Administrator account created after an administrator’s account was compromised, and relays the wiping of devices through Intune as the attackers’ own claim;^[79] a source familiar with the investigation told The Register that devices were wiped using Intune, and Microsoft declined to comment.^[80] Neither Stryker nor Microsoft has confirmed these details. Lesson: wipe is a feature, not malware, so defences belong in roles, sign-in, protected approver groups and bulk-action alerts (Automation and AI). Success metric: every destructive action approved by a second administrator from a protected group.

3. A stolen laptop (illustrative scenario; legal texts sourced). A manager’s laptop is stolen. The privacy team asks: was it encrypted, when did it last report, is the key escrowed? Under the EU’s GDPR, telling affected people is not required where measures “render the personal data unintelligible to any person who is not authorised to access it, such as encryption” and “were applied to the personal data affected” (Article 34(3)(a)), which in practice means the key was not exposed; notifying the supervisory authority within 72 hours (Article 33(1)) is a separate risk test, and every breach is documented (Article 33(5)).^[81] US health-care breach rules apply to “unsecured protected health information”, information not rendered “unusable, unreadable, or indecipherable” by methods in federal guidance.^[82] The encryption report proves the state at the last check-in, so check-in age matters. The legal call belongs to PrivacyOps; this is not legal advice.

4. Contractors on personal phones (illustrative scenario). Forty contractors need email and chat; they refuse enrolment. App protection “doesn’t require device management” and applies policies “only in a work context”.^[83] Where more is needed, Apple’s account-driven User Enrolment cannot query serial numbers or all apps and erases only managed data; no Apple method reads personal mail or messages or queries location outside Managed Lost Mode, which only ADE allows.^[27] Trade-off: less device assurance, so access requires a protected app. Success metric: onboarding within a day, no privacy complaints.

Worked calculation. Lab 1’s console showed 8 of 9 compliant (89%); reconciled, only 4 of 10 (40%) were managed, compliant, encrypted and EDR-healthy, so report the 40% and the named exceptions. At fleet scale (illustrative): 1,200 laptops, 1,164 encrypted, 1,131 with an escrowed key, so escrowed encryption is 1,131 ÷ 1,200 = 94.3%, and the 33 unescrowed devices are the ones an outage turns into reimages.

• Who can read keys. Seven built-in Entra roles can read BitLocker keys (as of October 2026): Cloud Device, Global, Helpdesk, Intune and Security Administrator, and the read-only Global Reader and Security Reader^[66] (Intune’s own BitLocker page still lists only three of them; the Entra role reference is authoritative). Users can read keys for their own devices unless a tenant toggle (default: allowed) stops them; every read is audited.^[28] Make these roles eligible through PIM, which needs extra licences,^[84] rather than standing; alert on bulk reads. LAPS rotation needs a custom Intune role.^[23]
• Personal devices. Microsoft states that an organisation using Intune can never see “Calling and web browsing history” or “Email and text messages”, while model and serial number are visible.^[85] Put the equivalent list for your tools in the BYOD notice.
• Jurisdiction. Notice, consent, works-council and monitoring rules differ by country and sector: agree them with PrivacyOps and ComplianceOps.

Costs are licences (EPM and similar controls are paid add-ons), EDR, hardware refresh, staff, and the service-desk time that strict policies create: measure tickets per 100 devices before and after each new rule.

Worked example: staying on Windows 10 (Microsoft list prices, as of October 2026). Extended Security Updates cost $61 per device for year one, “The price doubles every consecutive year” for at most three years, year one started in November 2025, and joining in year two means paying for year one too.^[86] So a device joining in year two costs $61 + $122 = $183, and 300 devices cost $54,900 for one more year of updates. Compare with upgrading or replacing hardware; carbon trade-offs are in GreenOps, cost modelling in FinOps.

flowchart TB
  A["Devices fail to boot after an update"]:::risk --> B["Pause rings; size the scope"]:::core
  B --> D{"Device still boots?"}:::decision
  D -->|yes| E["It pulls the fix; reboot"]:::core
  D -->|no| F{"Disk encrypted?"}:::decision
  F -->|no| G["Recovery media; apply fix"]:::core
  F -->|yes| H{"Key escrowed?"}:::decision
  H -->|yes| I["Key from second device or desk; then media"]:::core
  H -->|no| J{"TPM-only and LAPS?"}:::decision
  J -->|yes| K["Safe mode as local admin"]:::core
  J -->|no| L["Reimage, restore data"]:::risk
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029

1. Stabilise. Pause the rollout (ReleaseOps); open an incident with IncidentOps roles.
2. Size it. Devices whose UEM and EDR last-seen times stopped together are the affected set; export it with users and sites.
3. Unlock at scale. Publish the self-service key path;^[77] staff an audited desk queue; use the TPM-only safe-mode path where LAPS manages local admin passwords.^[22]
4. Repair with recovery media; reimage only what remains.
5. Rotate and verify. Rotate every key that was read (Intune’s BitLocker key rotation action supports Windows 10 1909 and later^[28]); confirm sensors report; reconcile.
6. Prevent: backfill escrow, add a monthly retrieval drill and ring control of agent updates.

• Encrypt first, escrow later: unrecoverable devices appear exactly when you need them back.
• Daily work as Global Administrator: one stolen session can wipe the fleet.^[40]
• Deleting stale records to improve the numbers: it removes evidence and sometimes recovery keys.
• Full enrolment demanded on personal phones: people forward mail to personal accounts instead.
• Myth: enrolling a phone lets IT read my messages. Not with Intune or Apple’s enrolment methods.^[85][27]

Invest in it when devices hold or reach company data, people work remotely, regulators or customers ask for device evidence, or personal devices reach company apps. Do less when work happens only in a browser or virtual desktop with no local data, or the organisation is very small: in this Atlas’s view a five-person firm gets most of the value from built-in encryption, automatic updates and strong sign-in. Hidden responsibilities: key retrieval at scale, the admin plane, BYOD notices, OS end-of-life migrations, reconciliation.

%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 16, "rankSpacing": 30, "padding": 8}}}%%
flowchart TB
  Q0{"Touches company data?"}:::decision
  Q0 -->|no| N["Guest access only"]:::neutral
  Q0 -->|yes| Q1{"Who owns it?"}:::decision
  Q1 -->|organisation| R1["Fully managed, zero-touch; dedicated mode if shared"]:::core
  Q1 -->|"person: Windows PC"| Q3{"Accepts whole-device management?"}:::decision
  Q1 -->|"person: other device"| Q4{"Phone or tablet, mail and office only?"}:::decision
  Q3 -->|yes| R2["Enrol as personal; privacy notice"]:::core
  Q3 -->|no| RW["Browser or virtual desktop; Edge app protection (preview)"]:::neutral
  Q4 -->|yes| R4["App protection, no enrolment"]:::core
  Q4 -->|no| Q5{"Accepts work separation?"}:::decision
  Q5 -->|yes| R5["Android work profile or Apple User Enrolment"]:::core
  Q5 -->|no| RX["Browser or virtual desktop only"]:::neutral
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029

Assumption: the identity provider can require either a compliant device or a protected app.

This Atlas’s model, not an industry standard; loosely comparable to the stages of CISA’s devices pillar.^[3]

New device ready for a user

• Enrolled by zero-touch
• Encrypted; recovery key escrowed (directory or management service)
• Baseline applied with no configuration errors or conflicts
• EDR sensor active, tamper protection on
• User is a standard user; LAPS backup present (Windows, and Macs set up by ADE)
• Compliant before the user receives it

Before a policy change

• Report-only or audit run reviewed
• Rings and rollback written; no setting already owned by another policy
• Break-glass accounts excluded from access policies
• Service desk briefed; user message ready

Admin-plane audit (monthly)

• No standing Global or Intune Administrator outside break-glass
• Second approver required for wipe, retire, delete, scripts and roles
• Approver group still a security group assigned to an Intune role; members direct, not nested
• Approver-group membership unchanged; no app exclusions on device actions
• Admin portals require phishing-resistant sign-in
• Bulk wipes and bulk key reads raise alerts

Lost or stolen device

• Intake form completed (template below)
• Encryption state and last check-in recorded before any action
• Lock, then wipe or retire according to ownership
• Sessions revoked; privacy team informed

LOST OR STOLEN DEVICE INTAKE
Reported by / time (UTC):      <name> / <YYYY-MM-DD hh:mm>
Device / serial / owner type:  <name> / <serial> / corporate | personal
Last check-in (UEM / EDR):     <time> / <time>
Encrypted at last check-in:    yes | no | unknown    Key escrowed: yes | no
Data likely on device:         <categories, e.g. customer, health, none known>
Actions and times:             lock <time>  wipe | retire <time>  sessions revoked <time>
Privacy decision owner:        <name>   Notification needed: <decided by privacy/legal>

DEVICE STANDARD EXCEPTION REQUEST
Control ID and rule:   <e.g. ADM-01 standard user>
Devices / users:       <list or group>
Business reason:       <why the control cannot be met now>
Compensating control:  <e.g. EPM elevation rule, extra monitoring>
Expiry (max 90 days):  <YYYY-MM-DD>     Approver (security): <name>
Review result:         renewed | closed | escalated

Is “EndpointOps” a job title or discipline? Neither, formally. The joined label appears as product names;^[5][6] the spaced form “endpoint operations” appears in job and team titles for endpoint engineering.^[88] No body defines either; search for endpoint management or endpoint security.

Does EDR replace device management? No. EDR detects and isolates; management sets encryption, OS versions and access state. They meet when EDR risk becomes a compliance rule.^[44]

Do phones need EDR? Decide per platform from your threat model (platform controls, app protection, mobile threat defence) and write it into the device standard, as Lab 1 does.

Retire or wipe? Retire removes company data and management; wipe “removes all personal and organizational data”.^[89] Wipe lost or reissued corporate devices; retire personal ones.

Should servers live in the same console? EDR often covers both; server configuration and patching belong to SysOps and PatchOps.

• Declarative management. Apple’s declarative device management reports status “without constant polling”,^[90] which should make compliance data fresher.
• The management plane as a security domain. Approvals now cover API calls as well as console actions;^[65] automation identities and approver groups are privileged.
• Governing local AI agents. Intune’s What’s new announced in June 2026 a preview baseline that detects and blocks a local AI agent (OpenClaw) on Windows; the baseline itself is dated May 2026 (as of October 2026).^[45][33]

Portfolio idea: a device standard, reconciliation script and runbook for a fictional 500-person firm.

• Decide: what “compliant” means (device standard); which mode each device class gets; who may wipe.
• Do: zero-touch enrolment; escrow before encrypt; EDR health; standard users; access gated on compliance or protected apps.
• Measure: reconciled coverage, escrowed encryption, EDR health, unmanaged access, key retrieval time.
• Watch out for: tenant defaults; deleting records that hold keys; standing admins and unprotected approver groups; console lag.

Situation. Security wants BitLocker keys readable only from compliant devices, an option Microsoft documents by treating keys as corporate resources.^[28] The service desk objects.

Assumptions: phishing-resistant MFA is in place for all users; key reads are audited and alerted on in bulk; keys rotate after use.

Decision for most organisations: B; A only for high-risk groups with a staffed desk path. A looks safer, but in a mass outage Microsoft told users to “use your phone” to fetch the key;^[77] under A most of those phones would fail the check and recovery would queue at the desk. Uncertainty: without phishing-resistant MFA, B’s risk rises sharply; fix that first.

After this page you can explain EndpointOps and why the label is informal; design a device standard and access policy; measure coverage by reconciliation; decide management modes and recovery trade-offs.

1. Your console shows 97% compliant. Name two reasons that number may be misleading.

2. A laptop finished BitLocker encryption an hour ago and still cannot reach email. What happened?

3. A cleanup script deletes device objects with no activity for 14 days. What two harms can it cause?

4. Why roll out a “require compliant device” policy in report-only mode first, and what side effect should you plan for?

5. An attacker gains an admin session in your UEM. Name three controls that limit what they can do.

6. A contractor refuses to enrol a personal phone but needs email. What do you offer?

“EndpointOps” is a product name and a convenient page title, not a discipline. The work behind it is old and real: knowing every device that touches your data, making its state visible and true, and letting that state decide access. The recent lessons are about recovery and power: a fleet is only as recoverable as the keys you can still read on the worst day, and a console that can wipe every device deserves the protection of a domain controller. Write the standard, configure to it, reconcile three records, gate access, drill recovery, and put a second pair of hands, from a group an attacker cannot quietly join, on every destructive action.

Claim-by-claim evidence: research/endpointops-ledger.md. Product behaviour and defaults change monthly; re-check vendor pages before relying on a setting or limit.

Changelog. 2026-10-17, r0: first version (research, ledger, draft, six diagrams, Lab 1 executed; Blueprint v2 structure; term status overlapping-synonym, as proposed in the coverage matrix); not yet independently reviewed. 2026-10-17, r1: answered review reviews/endpointops-r1.md (5 major, 18 minor; reviews/endpointops-r1-response.md): configuration playbook; unenrolled-device mechanism; seven key-reading roles; MAA approver group; macOS 26.4 FileVault; plan limits; macOS LAPS; GDPR Article 33(1); Lab 1 robustness; Lab 3 roles; personal Windows PCs in the decision tree; repetition cut; canonical URLs. 2026-10-17, r2: answered reviews/endpointops-r2.md and the 87/100 score (reviews/endpointops-r2-response.md): Stryker attack path attributed source by source; decision tree adds opt-in enrolment of personal Windows PCs and routes personal Macs to User Enrolment; MAA approver-group preconditions; Apple Business dated to its announcement; compliance partners; Linux and ChromeOS boundary; client-driven evaluation marked preview; code blocks wrapped to 90 characters (Lab 1 re-executed); RACI and rounding fixes. 2026-10-17, post-score polish (reviews/endpointops-polish.md): figures 1 and 6 redrawn; warning callout and MAA preconditions as lists; OMB M-22-01 added; NIST SP 800-124 cited; repetition trimmed; client-driven evaluation no longer called a preview.