--- title: "EndpointOps" slug: endpointops category: security term_status: overlapping-synonym evidence_status: verified summary: "EndpointOps is an informal name for running user devices through their whole life: enrolment, configuration, compliance, encryption, EDR health, access decisions and retirement, where IT management and security meet. The practice is established as endpoint management plus endpoint security." audience: [Beginners, Endpoint and desktop engineers, IT administrators, Security engineers, Architects, IT and security leaders] last_verified: 2026-10-17 key_takeaways: - "EndpointOps is not a defined discipline. The label's most visible use is a product module (Zirozen's EndpointOps); the practice behind it is endpoint management (MDM and UEM) plus endpoint security (EDR), and this page teaches it under those names." - "The unit of work is the managed device across its life: procure, enrol, configure, prove compliance, protect, recover, retire. Configuration sets the state; compliance checks it; a device missing from management, EDR or the identity provider is not under control." - "Compliance protects nothing until it gates access, and defaults can undo it: Intune treats an enrolled device that no compliance policy targets as compliant unless you change one tenant setting." - "Encryption is half a control without escrowed, retrievable recovery keys. In July 2024 a faulty EDR update turned key retrieval into a fleet-scale recovery task." - "The management console is itself a weapon. After the March 2026 Stryker attack, CISA urged least-privilege roles, phishing-resistant MFA and multi-admin approval; an approval step is only as strong as the group of approvers." - "Personal devices need a different contract: app-level protection, user enrolment or opt-in whole-device enrolment, with written limits on what IT can see and erase." - "Measure by reconciling management, EDR and identity-provider records, not by one console's compliance percentage." related: [patchops, identityops, vulnerabilityops, soc-ops, accessops, secops, sysops, iotops] --- ## What EndpointOps is ### In 30 seconds **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. ### At a glance | Question | Answer | |---|---| | Goal | Devices that reach company data are known, compliant, encrypted with a retrievable key, watched by a healthy sensor, and erasable | | Users | Endpoint and desktop engineers, IT administrators, security engineers, service desk, identity architects | | Scope on this page | Corporate and personal ("bring your own device", BYOD) laptops, desktops, phones and tablets from zero-touch enrolment to retirement, including the management plane; Linux desktops and ChromeOS as a boundary | | Out of scope | Patching → [PatchOps](../patchops/); fix priorities → [VulnerabilityOps](../vulnerabilityops/); alert triage → [SOC Ops](../soc-ops/); sign-in → [IdentityOps](../identityops/); servers → [SysOps](../sysops/); choosing baselines → [SecOps](../secops/); constrained devices → [IoTOps](../iotops/) | | Prerequisites | None. [SysOps](../sysops/) and basic identity concepts help | | Key outputs | Device standard, compliance and access policies, reconciled inventory, exception register, recovery runbooks | | Term status | Overlapping synonym for endpoint management plus endpoint security (see [What EndpointOps is not](#what-endpointops-is-not)) | ### The problem it solves 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".[^nist-endpoint] 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".[^cis-c1] 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".[^ztmm] 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."[^nist-207] | Without a device discipline | With one | |---|---| | "Encrypted" means someone ticked a box | Encryption reported per device; recovery key escrowed first | | EDR installed once, never checked | Sensor health reconciled with the inventory weekly | | Any device with a password reaches data | Access requires a compliant device or a protected app | | Any admin can wipe the fleet | Scoped roles and a second approver for destructive actions | ### What EndpointOps is not - **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".[^trinetri] A PowerShell toolkit for SentinelOne and CyberArk Endpoint Privilege Manager also names its module EndpointOps.[^gh-endpointops] This page is about neither. - **Not alert triage or incident response.** EndpointOps keeps EDR deployed and healthy; alerts belong to [SOC Ops](../soc-ops/), detections to [DetectionOps](../detectionops/), intrusions to [ResponseOps](../responseops/). - **Not patching.** Rings and patch compliance belong to [PatchOps](../patchops/), fix priorities to [VulnerabilityOps](../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](../identityops/), elevation to [AccessOps](../accessops/); this page supplies the device signal. - **Not servers, IoT or app releases:** [SysOps](../sysops/), [IoTOps](../iotops/) and [MobileOps](../mobileops/). ::: note Term status and editorial distinction This Atlas classes EndpointOps as an **overlapping synonym**: a rare label for an established practice better known as endpoint management (MDM, UEM) plus endpoint security (EDR); a product using the name is a collision, not evidence of a discipline. The boundaries above are an **editorial distinction** so that each topic is taught once; no standard draws them, and one small team often does all of it. ::: ## Where EndpointOps comes from and where it sits ### Origins and evolution **Management.** PCs had client management tools and smartphones MDM; enterprise mobility management (EMM) suites added app management,[^nist-124] and the combined category became unified endpoint management.[^wiki-uem] Operating systems built management in: Windows ships "A built-in management component" for MDM servers,[^win-mdm] and Apple's Automated Device Enrolment (ADE) manages devices "from the moment someone removes a device from its box".[^apple-ade] 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.[^apple-business][^apple-ade] **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;[^chuvakin] the shorter "EDR" stuck. **Convergence.** Zero trust made device posture an input to access (NIST SP 800-207, 2020).[^nist-207] CISA's maturity model 2.0 (April 2023) points agencies to OMB memorandum M-22-01 on EDR.[^ztmm][^omb-edr] Intune's endpoint security node gives "security admins a central location".[^intune-endpointsec] A faulty EDR update in 2024 and a console attack in 2026 moved attention to recovery and the management plane ([Use cases](#use-cases-and-scenarios)). ### Glossary and mental model | Term | Meaning | Why it matters | |---|---|---| | Enrolment | Registering a device with a management service | Unenrolled devices receive no controls | | Zero-touch enrolment | Vendor or reseller links the serial to your tenant; first boot enrols it | No hand imaging[^autopilot][^apple-ade][^android-zt] | | Configuration profile | Settings the service pushes to the device: desired state | Configuration sets state; compliance checks it | | Compliance policy | Rules a device is evaluated against: compliant or noncompliant | Feeds access decisions | | Conditional Access | Identity-provider policy that grants or blocks sign-in on conditions, including compliance | Turns device state into access[^ca-compliant] | | App protection (MAM) | Mobile application management: policies on work apps and their data, not the device | The usual BYOD option on phones; not offered on macOS[^intune-appmgmt] | | Work profile / User Enrolment | Android and Apple separation of work data on personal devices | Limits what IT can see and erase[^android-wp][^apple-ue] | | Antivirus versus EDR | Antivirus blocks mainly known threats; an EDR sensor records behaviour to catch what prevention missed | Healthy antivirus is not a healthy sensor[^omb-edr][^cs-edr] | | TPM and protectors | Trusted Platform Module, the chip that releases the disk key; protectors are unlock methods (TPM-only, TPM plus PIN, recovery password) | Decide what recovery needs[^ms-recoverytool] | | LAPS | Local Administrator Password Solution: unique, rotated local admin passwords | A recovery path[^intune-laps] | **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. ### How EndpointOps relates to other Ops ::: figure Where EndpointOps sits among its neighbours ```mermaid 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 ``` Text equivalent: SecOps supplies the baselines, VulnerabilityOps the fix priorities and PrivacyOps the BYOD terms that EndpointOps applies. EndpointOps sends the device compliance signal to IdentityOps, whose access policy uses it, and hands update rollout to PatchOps, EDR alerts to SOC Ops and elevation to AccessOps. ::: | Neighbour | This page | The neighbour | |---|---|---| | [PatchOps](../patchops/) | Whether an outdated device may still reach data | Rings, windows, rollback, patch compliance | | [VulnerabilityOps](../vulnerabilityops/) | Applying the fix as configuration | Prioritisation and due dates | | [SOC Ops](../soc-ops/), [DetectionOps](../detectionops/) | Sensor deployment, health, coverage | Alert triage, detection content | | [IdentityOps](../identityops/) | The device compliance signal | Accounts, SSO, MFA, sign-in policy | | [AccessOps](../accessops/) | Hardened admin workstations | Elevation, approvals, sessions | | [SecOps](../secops/) | Applying baselines on user devices | Choosing baselines, approving exceptions | | [SysOps](../sysops/), [IoTOps](../iotops/) | Laptops, desktops, phones, tablets | Servers; constrained devices | | [PrivacyOps](../privacyops/) | What the tooling can see and erase | Legal basis, notices, retention | ## Principles and operating model ### Charter and principles **Charter (this Atlas's proposal, not a published standard):** the goal in [At a glance](#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.[^apple-filevault] 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. ### Fundamentals: the building blocks | Building block | Windows | Apple (macOS, iOS, iPadOS) | Android | Typical failure | |---|---|---|---|---| | Zero-touch enrolment | Windows Autopilot[^autopilot] | Automated Device Enrolment via Apple Business[^apple-ade][^apple-business] | Zero-touch enrolment[^android-zt] | Devices bought outside the channel | | Personal-device mode | Opt-in enrolment as a personal device,[^intune-winenrol] or Edge app protection (preview)[^ca-grant] | Account-driven User Enrolment (iOS, iPadOS, macOS 14+)[^apple-ue][^apple-methods] | Work profile[^android-wp] | Users refuse full enrolment | | Disk encryption | BitLocker, key in Entra ID[^intune-bitlocker] | FileVault enforced in Setup Assistant, key escrowed to the management service[^apple-filevault] | Platform encryption; verify per model | Key never escrowed | | Local admin control | Windows LAPS;[^intune-laps] Endpoint Privilege Management (licensed add-on)[^intune-epm] | Standard users; Intune macOS LAPS for Macs set up by ADE after a factory reset[^intune-laps] | Not applicable | Everyone is a local admin | | Application control | App Control for Business, AppLocker[^applocker] | Santa (open source) or vendor tools[^santa] | Managed Google Play | Enforced without audit | | EDR | Defender for Endpoint, CrowdStrike Falcon, others[^mde][^cs-edr] | Same vendors | Mobile threat defence apps | Silently unhealthy | | Baselines | Intune security baselines;[^intune-baselines] CIS Benchmarks[^cis-bench] | macOS Security Compliance Project[^mscp] | Vendor guidance | Untested conflicts | **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.[^intune-linux][^ca-grant] 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.[^intune-chromeos] 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). ### Roles, ownership and RACI R = responsible, A = accountable, C = consulted, I = informed. | Activity | Endpoint engineering | Security engineering | Identity team | Service desk | Privacy or legal | |---|---|---|---|---|---| | Device standard (what "compliant" means) | R | A (security settings) | C | C | C (BYOD) | | Enrolment profiles and zero-touch | R/A | I | C | C | I | | Compliance and configuration policies | R/A | C | I | I | I | | Access policy using compliance | C | C | R/A | I | I | | EDR deployment and health | R | A | I | I | I | | Recovery keys and LAPS retrieval | R/A (escrow, retrieval path) | C | C | R (retrieval) | I | | Lost device: lock, wipe, evidence | R | C | C | R (intake) | A (notification decision) | | BYOD terms and what IT can see | C | C | I | I | A | | Management-plane roles and approvals | R | A | C | I | I | ### Lifecycle of a managed device ::: figure The life of a managed device from purchase to disposal ```mermaid 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 --> [*] ``` Text equivalent: A procured device is registered for zero-touch enrolment when its serial is linked to the tenant; at first boot the user signs in and it is enrolled, configured and, once evaluated, compliant. A failing rule (drift) makes it noncompliant within a grace period; a fix returns it to compliant, and when grace ends it is blocked until fixed. A device silent past the validity period is blocked directly. Lost devices are locked and wiped; leavers and refreshes are retired, then reset for reuse or sanitised and disposed of. ::: CISA's model says the device lifecycle "includes procuring, configuring, tracking, monitoring, updating, using, sanitizing, deprovisioning, and recovering devices".[^ztmm] - **Day 0:** the device standard ([Reference implementation](#reference-implementation-a-device-standard-and-its-intune-expression)), 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.[^autopilot] - **Day 2:** compliance, drift, sensor health, reconciliation, exceptions, lost devices, OS lifecycle (Windows 10 support ended on 14 October 2025[^win10-eos]). - **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".[^nist-88] ### Operating model and governance | Cadence | Activity | Output | |---|---|---| | Daily | Enrolment failures, new noncompliant devices, silent sensors | Tickets, or "none" | | Weekly | Three-source reconciliation; stale devices; configuration errors and conflicts | Exceptions with owners | | Monthly | KPI review; one key-retrieval and one remote-lock drill; admin-role and approver-group review | KPI trend; drill record | | Quarterly | Revise the device standard for new OS releases; review BYOD terms and expired exceptions | New standard version | **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](../patchops/) does, through [ITOps](../itops/) change control; agent content updates are governed in [SecOps](../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.[^ms-intune-bp] ## Architecture and workflow ### Reference architecture ::: figure Reference architecture: the device, the services that act on it, and the admin plane ```mermaid 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 ``` Text equivalent: Administrators act on the UEM service through scoped, time-bound roles and a second approver; zero-touch services tell it which devices belong to the organisation. The UEM service and the device exchange policy and check-ins. The device sends telemetry to the EDR service, which returns a risk level to the UEM service and sends alerts to the security information and event management (SIEM) system and security operations centre (SOC). The device also escrows its recovery key and local admin password to the directory. The UEM service writes a compliance flag to the identity provider, whose access policy issues a token for company apps and data, or blocks. ::: | Component | Responsibility | Trust boundary and trade-off | |---|---|---| | UEM service | Desired state, compliance, inventory, wipe | Its admins can wipe every device[^cisa-stryker] | | Management client | Applies policy, reports at check-in | The console lags the device | | EDR sensor and service | Telemetry, detection, isolation, risk | Deep OS privilege; a bad update can crash the fleet[^cs-rca] | | Directory | Device objects, recovery keys, LAPS | Keys must be readable when the device is down | | Identity provider | Access policy using compliance | Only as good as the compliance data | **Alternatives:** per-platform tools, or app-only management, if the [Lab 1](#lab-1-beginner-reconcile-three-inventories) reconciliation covers every source. ### End-to-end workflow: from device state to access ::: figure The compliance-to-access loop, with grace period and lost contact ```mermaid 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 ``` Text equivalent: A device checks in roughly every eight hours. If it passes, it is compliant and gets access at sign-in. If it fails and a grace period is set, the user is notified and keeps access until grace ends unless it is fixed in time; with no grace period it is blocked at once. Blocked devices are fixed and check in again. A device silent past the validity period is blocked too. ::: **Happy path (Intune and Entra, as of October 2026).** Devices check in "about every 8 hours";[^intune-refresh] 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.[^intune-win-compliance] Microsoft announced this client-driven evaluation in September 2026.[^intune-whatsnew] An access policy with "Require device to be marked as compliant" grants or blocks.[^ca-compliant] **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.[^intune-noncompliance] A device silent beyond the "Compliance status validity period" (30 days by default) is treated as noncompliant.[^intune-compliance] ::: warning Two settings that quietly undo the design 1. **No policy counts as compliant.** Intune's tenant setting *Mark devices with no compliance policy assigned as* defaults to **Compliant**, so an **enrolled** device that no policy targets passes a "require compliant device" check. Microsoft's advice for tenants that use Conditional Access is to "change this setting to Not compliant".[^intune-compliance] Unenrolled devices fail the check, which needs devices "registered with Microsoft Entra ID and enrolled with Intune" (or, for Windows, marked compliant by a non-Microsoft MDM set up as an Intune compliance partner);[^ca-grant] reconciliation finds them. 2. **The BitLocker check waits for a reboot.** The Windows setting *Require BitLocker*, a Device Health Attestation check, is measured at boot: a freshly encrypted device stays noncompliant until it reboots. *Encryption of data storage on a device* only "generically checks for the presence of encryption"; Microsoft calls *Require BitLocker* more robust.[^intune-win-compliance] ::: 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.[^intune-win-compliance] ## Practices, standards and tools ### Core practices and playbooks | Practice | Trigger | Owner | Output | Verification | |---|---|---|---|---| | Zero-touch enrolment | Purchase | Endpoint engineering | Serial registered | First-boot test per model | | Encrypt with escrow | Enrolment | Endpoint engineering | Disk encrypted, key escrowed | Monthly retrieval drill | | EDR health | Weekly | Security engineering | Active sensor, tamper protection | Silent more than 7 days = ticket | | Remove local admin | Rollout | Endpoint engineering | Standard users, LAPS | Local admin group report | | BYOD onboarding | Request | Endpoint with privacy | App protection or user enrolment | Notice acknowledged | | Lost device | Report | Service desk | Lock, wipe, evidence | Encryption state recorded | 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.[^mde-health] Tamper protection "helps protect important security settings from being disabled or changed".[^mde-tamper] #### Playbook: configuration and hardening baselines Here the baselines that [SecOps](../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.[^intune-catalog] 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".[^intune-catalog] 2. **Layer, with one owner per setting.** Vendor baseline, then a benchmark (CIS Benchmarks;[^cis-bench] mSCP for macOS[^mscp]), then exceptions approved by SecOps. Separate baselines "might include the same settings and use different default values".[^intune-baselines] Intune shows conflicts between configuration policies and says "Manually resolve these conflicts"; for conflicting custom Apple profiles "Apple randomly applies the settings".[^intune-refresh] So each setting gets one owning policy. 3. **Find drift.** Review the per-policy reports for errors and conflicts weekly;[^intune-refresh] 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.[^intune-remediations] 4. **Roll out in rings**, as for any policy change ([Operating model](#operating-model-and-governance)). | Everyday control | Windows (Intune) | macOS | Watch for | |---|---|---|---| | Host firewall | Endpoint security firewall policy[^intune-endpointsec] | Firewall policy, same node | Baseline firewall defaults "might not merge" local rules with MDM rules[^intune-baselines] | | Removable media, peripherals | Defender device control; Windows device installation settings[^mde-devctl] | Defender device control for Mac | Over-broad rules (all USB, all Bluetooth) also block headsets | | Browser | Edge security baseline[^intune-baselines] | Settings catalog (Edge, Safari)[^intune-catalog] | A second, unmanaged browser | | Wi-Fi and VPN certificates | SCEP or PKCS certificate profiles[^intune-certs] | A separate profile per platform | Expiring issuing certificates | | Screen lock, passcode | Settings catalog or baseline | Declarative passcode settings[^intune-catalog] | Duplicate settings in two policies | #### Playbook: audit, then enforce 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.[^mde-asr] Prefer App Control for Business: customers able to use it "should do so", while AppLocker "isn't getting new feature improvements".[^applocker] On macOS, Google stopped maintaining Santa in 2025 and points to the North Pole Security fork.[^santa] 2. **Build rules** from audit data by publisher, not path (NIST SP 800-167 covers planning).[^nist-167] 3. **Enforce in rings** with a named rollback; run exceptions with expiry dates ([Templates](#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".[^cisa-rmm] ### Methods, standards and frameworks NIST SP 800-124 Rev. 2 (2023) covers mobile devices across "deployment, use and disposal";[^nist-124] 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;[^nist-1800-22] SP 800-111 (2007) and SP 800-167 (2015) are the older basics of storage encryption and allow-listing.[^nist-111][^nist-167] For hardening, CIS Benchmarks and vendor baselines: Intune's defaults are "the most restrictive" in almost all scenarios.[^cis-bench][^intune-baselines] 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. ### Tooling landscape Product facts as of October 2026. | Category | Job | Verified examples | Selection criteria and risks | |---|---|---|---| | UEM / MDM | Enrol, configure, compliance, remote actions | Microsoft Intune (Android, iOS/iPadOS, Linux, macOS, tvOS, visionOS, Windows);[^intune-overview] Jamf Pro (Apple);[^jamf] Omnissa Workspace ONE;[^omnissa-ws1] Fleet (open source);[^fleet] MDM built into Apple Business[^apple-business] | Platforms, identity integration, API, approvals, exit cost | | EDR / XDR (extended detection and response) | Detect, isolate, report risk | Microsoft Defender for Endpoint;[^mde] CrowdStrike Falcon[^cs-edr] | OS coverage, update-timing control, tamper protection | | Endpoint query | Ask devices questions in SQL | osquery[^osquery] | Query cost, who may run queries | | Privilege | Remove standing local admin | Windows and macOS LAPS;[^intune-laps] Intune Endpoint Privilege Management (Intune Plan 2, Intune Suite or some Microsoft 365 bundles, as of October 2026)[^intune-epm] | Elevation rules that users understand | | Telemetry | Detailed host events | Sysmon, which logs "system activity to the Windows event log"[^sysmon] | Volume and cost; pipelines belong to [SecDataOps](../secdataops/) | **Lock-in.** Policies and enrolment profiles do not move between vendors: keep the device standard tool-neutral and export policies as code. ### Automation and AI 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.[^intune-maa] **MAA is only as strong as its approver group.** Three documented conditions decide whether it works at all:[^intune-maa] 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[^entra-roles] (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".[^intune-maa] 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.[^intune-actions] AI agents for remediation and change review are in preview in Intune (as of October 2026);[^intune-whatsnew] treat their output as proposals and evaluate them as [AIOps for Security](../aiops-for-security/) describes. ## EndpointOps in practice ### Reference implementation: a device standard and its Intune expression **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._ ```yaml # 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;[^graph-compliance] Graph requires exactly one `block` scheduled action per policy, with `ruleName` fixed to `PasswordRequired`, and `gracePeriodHours` sets the delay.[^graph-compliance] 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._ ```json { "@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;[^graph-ca] 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.[^ca-reportonly] _Example status: JSON syntax-checked, not executed. Replace the two object IDs._ ```json { "displayName": "PILOT report-only: Windows requires compliant device", "state": "enabledForReportingButNotEnforced", "conditions": { "clientAppTypes": ["all"], "applications": { "includeApplications": ["All"] }, "users": { "includeGroups": [""], "excludeUsers": [""] }, "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;[^intune-bitlocker] LAPS;[^intune-laps] Multi Admin Approval with a protected approver group;[^intune-maa] emergency access accounts excluded from access policies.[^ca-compliant] ### Hands-on labs #### Lab 1 (beginner): reconcile three inventories **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`. ```text 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._ ```python #!/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): ```text 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`[^graph-md]); VMs and replaced boards can change serials. **Teardown:** delete real exports. #### Lab 2 (intermediate): what the device says versus what the console says **Objective:** measure how far the console lags the device. **Prerequisites:** an enrolled test Windows device, local admin rights, optionally osquery;[^osquery] 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._[^lab2-docs][^osquery-specs] ```powershell # 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' ``` ```sql -- 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)[^intune-refresh] and time the console update. 4. If encryption finished recently but the device shows noncompliant, reboot: *Require BitLocker* is measured at boot.[^intune-win-compliance] **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;[^ca-grant] an empty `bitlocker_info` usually means osquery is not elevated. **Teardown:** uninstall osquery if added. #### Lab 3 (advanced): compliance to access, in report-only mode **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"[^ca-overview]); 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;[^lab3-docs] 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._[^lab3-docs] ```powershell # 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](#reference-implementation-a-device-standard-and-its-intune-expression) 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).[^intune-noncompliance] 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.[^ca-reportonly] **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.[^lab3-docs] **Teardown** (then revert step 1 if the tenant is shared): ```powershell $g = "https://graph.microsoft.com/v1.0" Invoke-MgGraphRequest -Method DELETE ` -Uri "$g/identity/conditionalAccess/policies/" Invoke-MgGraphRequest -Method DELETE ` -Uri "$g/deviceManagement/deviceCompliancePolicies/" Disconnect-MgGraph ``` In production, keep report-only for at least a business week, review, then set `state` to `enabled` for the pilot before widening. ### Use cases and scenarios **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".[^ms-crowd] Microsoft warned "You may be asked to enter your BitLocker recovery key" and told users to "use your phone" to fetch it.[^kb5042421] 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.[^ms-recoverytool] CrowdStrike reported about 99% of Windows sensors back online by 29 July.[^cs-rca] *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".[^stryker] 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)".[^cisa-stryker] Stryker's page does not describe the attack path.[^stryker] 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;[^bc-stryker] a source familiar with the investigation told The Register that devices were wiped using Intune, and Microsoft declined to comment.[^reg-stryker] 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](#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)).[^gdpr] US health-care breach rules apply to "unsecured protected health information", information not rendered "unusable, unreadable, or indecipherable" by methods in federal guidance.[^hipaa] The encryption report proves the state at the last check-in, so check-in age matters. The legal call belongs to [PrivacyOps](../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".[^intune-app] 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.[^apple-methods] *Trade-off:* less device assurance, so access requires a protected app. *Success metric:* onboarding within a day, no privacy complaints. ## Measure, govern, pay ### Metrics and KPIs | KPI | Formula | Data source | Pitfall | |---|---|---|---| | Management coverage | Devices with a UEM check-in in 30 days ÷ active devices (seen anywhere in 30 days) | Reconciliation (Lab 1) | Console-only denominators omit unmanaged devices | | EDR health coverage | Active sensors seen in 7 days ÷ active devices that require EDR | EDR, reconciliation | "Installed" is not healthy | | Escrowed encryption | Devices encrypted **and** with a key escrowed ÷ managed devices | Encryption report, directory | Unescrowed encryption is a lock-out risk | | Honest compliance rate | Compliant devices with at least one policy ÷ managed devices | UEM | Excludes default-compliant devices | | Unmanaged access share | Sign-ins from devices neither managed nor app-protected ÷ all sign-ins to protected apps | Identity-provider logs | Needs device identity in logs | | Supported-OS share | Devices on a release still in security support ÷ active devices | UEM plus vendor calendars | Paid extended support buys a date, not a fix | | Key retrieval time | Minutes from request to usable key, monthly drill | Service desk | Untested paths fail in outages | | Approved destructive actions | Wipes, retires, deletes with a second approver ÷ all of them | UEM audit log | Review the break-glass path | **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. ### Security, privacy and compliance - **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[^entra-roles] (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.[^intune-bitlocker] Make these roles eligible through PIM, which needs extra licences,[^entra-pim] rather than standing; alert on bulk reads. LAPS rotation needs a custom Intune role.[^intune-laps] - **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.[^intune-see] 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](../privacyops/) and [ComplianceOps](../complianceops/). ### Cost, capacity and sustainability 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.[^win10-esu] 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](../greenops/), cost modelling in [FinOps](../finops/). ### Assurance of the operating model | Risk indicator | Healthy signal | Check | |---|---|---| | Unmanaged devices signing in | Zero, or each one has a ticket | Weekly reconciliation | | Sensors silent for more than 7 days | Each has an owner and a date | Weekly EDR health report | | Exceptions past expiry | None | Monthly exception review | | Standing privileged admins; approver-group changes | None outside break-glass accounts; none unexplained | Monthly role review | | Key retrieval untested | One successful drill a month | Drill log | ## When things go wrong ### Common failures and troubleshooting | Symptom | Likely cause | Diagnose | Fix and prevent | |---|---|---|---| | Enrolled devices with no compliance policy pass "require compliant device" | The tenant default counts them as compliant | Tenant compliance settings | Set to Not compliant after a report-only run[^intune-compliance] | | Encrypted device still noncompliant | *Require BitLocker* is measured at boot | Encryption report versus last reboot | Reboot; tell users in the notification[^intune-win-compliance] | | Silent BitLocker never starts | A baseline requires a TPM startup PIN, other encryption exists, or the 200-key limit is hit | Baselines, inventory | Remove conflicts; pilot first[^intune-bitlocker] | | A setting does not apply as expected | Two policies set it differently | Policy report shows a conflict | One owning policy per setting[^intune-refresh] | | Recovery key gone after cleanup | Deleting an Entra-joined device's Intune object removes key protectors, suspending BitLocker | Audit log | Disable first; keep keys[^intune-bitlocker][^entra-stale] | | Many devices "inactive" in EDR | Reimaged or renamed devices get new records | EDR list by serial | Reconcile by serial or directory ID[^mde-health] | | Cleanup deleted a laptop in use | Activity timestamp updates only about every 14 days | Directory audit | Under 21 days is not stale; disable before delete; keep Autopilot objects[^entra-stale] | | LAPS password not rotating | Device disabled in the directory | Device object state | Re-enable or retire[^intune-laps] | ### Worked runbook: a fleet that cannot boot ::: figure Runbook when many devices fail to boot after an update ```mermaid 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 ``` Text equivalent: When devices fail to boot after an update, pause the rings and size the scope. Devices that still boot pull the fix and reboot. Unencrypted disks are fixed from recovery media; encrypted disks with an escrowed key are unlocked with the key from a second device or the service desk, then repaired. Without a key, TPM-only devices with a LAPS-managed admin password are fixed in safe mode; the rest are reimaged and their data restored. ::: 1. **Stabilise.** Pause the rollout ([ReleaseOps](../releaseops/)); open an incident with [IncidentOps](../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;[^kb5042421] staff an audited desk queue; use the TPM-only safe-mode path where LAPS manages local admin passwords.[^ms-recoverytool] 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[^intune-bitlocker]); confirm sensors report; reconcile. 6. **Prevent:** backfill escrow, add a monthly retrieval drill and ring control of agent updates. ### Anti-patterns and myths - **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.[^ms-intune-bp] - **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.[^intune-see][^apple-methods] ## Deciding and adopting ### When to use EndpointOps and when not to **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. ### Decision framework: how much to manage a device ::: figure Choosing a management mode for a device ```mermaid %%{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 ``` Text equivalent: A device that never touches company data gets guest access only. Organisation-owned devices are fully managed through zero-touch enrolment, in dedicated mode if shared or single-purpose. A personal Windows PC has no work-profile mode: if the owner accepts whole-device management it is enrolled as a personal device, with a privacy notice;[^intune-winenrol] if not, it gets a browser or virtual desktop, or app protection in Microsoft Edge (a preview as of October 2026).[^ca-grant] A personal phone or tablet that needs only mail and office apps gets app protection without enrolment. Every other personal device, including every Mac (Intune offers no app protection on macOS[^intune-appmgmt]), depends on whether the owner accepts work separation: an Android work profile or Apple User Enrolment (macOS 14 and later[^apple-methods]) if yes, browser or virtual desktop only if not. ::: Assumption: the identity provider can require either a compliant device or a protected app. ### Maturity model **This Atlas's model**, not an industry standard; loosely comparable to the stages of CISA's devices pillar.[^ztmm] | Level | Observable behaviour | Evidence | Next step | |---|---|---|---| | 0. Unknown | Devices set up ad hoc; no single inventory | None | Enrol corporate devices | | 1. Enrolled | Most devices enrolled; default policies; EDR installed | UEM device list | Write the device standard | | 2. Enforced | Baseline applied; compliance gates access; escrowed encryption; app protection on personal devices | Access-policy reports | Reconcile and measure | | 3. Reconciled | Weekly three-source reconciliation; KPIs; expiring exceptions; admin plane hardened | KPI trend, role reviews | Drill recovery | | 4. Resilient | Monthly key-retrieval drills; rings for policy and agent changes; second approver on destructive actions | Drill records | Keep pace with OS releases | ### Adoption roadmap: 30/60/90 days | Window | Actions | Exit criteria | |---|---|---| | Days 1–30 | Run Lab 1 on real exports; write the device standard; fix tenant defaults in report-only; inventory admin roles | Exceptions listed with owners; standard approved | | Days 31–60 | Escrow keys and backfill missing ones; enforce compliance for the pilot ring; app protection for personal phones; LAPS | Pilot enforced; escrowed encryption above 95% | | Days 61–90 | Enforce broadly; second approver from a protected group for wipes and role changes; first key-retrieval drill | Drill passed; first KPI review held | ## Toolkit ### Checklists **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 ### Templates ```text LOST OR STOLEN DEVICE INTAKE Reported by / time (UTC): / Device / serial / owner type: / / corporate | personal Last check-in (UEM / EDR):