Standardised endpoint security across 20+ subsidiaries — Intune compliance baseline, ring-based Autopilot rollout, and Defender for Endpoint RBAC scoped per subsidiary.
Körber is an industrial manufacturing group operating across more than 20 subsidiaries, each with varying degrees of IT autonomy. Endpoint security was fragmented: different AV products across subsidiaries, inconsistent patch management, and no unified compliance baseline. Some subsidiaries had Intune partially deployed; others were managing devices entirely through Group Policy with no cloud management plane.
The challenge was not simply technical — it was organisational. Subsidiaries had different IT teams, different risk profiles, and different operational constraints (factory floor devices, for example, have very different patch tolerance compared to corporate office endpoints). Any approach that treated the estate as homogeneous would fail.
The engagement required a framework that could be applied consistently across all subsidiaries while accommodating legitimate operational differences.
The design mattered because the objective was not just to deploy Intune and Defender centrally, but to create a control model that could scale across autonomous subsidiaries without forcing every business unit into the same operational template on day one.
The endpoint design separated central governance from subsidiary execution, combining Intune, Defender, Conditional Access, and ring-based rollout controls so standards could scale across 20+ operating companies.
The architecture was built around three principles:
Subsidiary-scoped RBAC — Each subsidiary's IT team received Intune and Defender for Endpoint RBAC permissions scoped to their own device group. Cross-subsidiary visibility was restricted to the central security team. This preserved subsidiary autonomy while enabling central oversight.
Ring-based rollout — Policies were deployed using a four-ring model: IT pilot, early adopters, general deployment, enforcement. Each ring was an Entra ID dynamic group. Progression between rings required a defined validation window with no unresolved compliance failures.
Separation of compliance from enforcement — Intune compliance policies defined what a "healthy" device looked like. Conditional Access enforced the compliance requirement. These were configured independently, allowing compliance visibility before enforcement was enabled — eliminating the risk of locking users out before issues were resolved.
The engagement ran across five sprints, covering the full lifecycle from baseline design to enforcement and handover.
Sprint 1 — Inventory and baseline design
A device audit across all subsidiaries produced a clear picture of the estate: OS versions in circulation, existing AV products, Intune enrolment status, and legacy Group Policy configurations that would conflict with Intune management. This audit drove the compliance policy configuration — minimum OS versions, required security controls, and exclusion categories for factory floor devices.
Defender for Endpoint device groups were created per subsidiary in the Defender portal. RBAC roles were defined: Security Reader (subsidiary IT), Security Analyst (subsidiary IT leads), Security Engineer (central team), SOC Manager (central team only).
Sprint 2 — Intune compliance and configuration baseline
Compliance policies were deployed to the IT pilot ring across all subsidiaries simultaneously. The policy covered: minimum OS version, BitLocker encryption, Defender real-time protection active, no jailbreak, Secure Boot enabled. Devices failing compliance were marked non-compliant in Intune — but Conditional Access enforcement was not yet enabled.
Configuration profiles deployed the Windows Security Baseline, LAPS (Local Administrator Password Solution) via Intune, and OneDrive Known Folder Move (silent). App packaging for common business applications was completed for the Company Portal.
Sprint 3 — Defender for Endpoint deployment
MDE was deployed to the pilot ring via Intune Endpoint Security policy. The legacy AV products were removed — sequenced carefully to avoid a gap in protection — and MDE moved to active mode. ASR rules were deployed in audit mode, reviewed over 14 days, and moved to block mode rule by rule.
Network Protection was enabled in block mode after the audit period confirmed no false-positive blocking of legitimate business traffic.
Sprint 4 — Conditional Access and MDO
Conditional Access was updated to require device compliance. Policies were deployed in report-only mode for 14 days across all rings, with sign-in log reviews identifying service accounts and legacy auth dependencies that needed to be excluded before enforcement.
Defender for Office 365 Standard preset was applied to all mailboxes. Strict preset was applied to priority accounts (executive team, finance leads, subsidiary IT admins). Safe Links and Safe Attachments were confirmed active in the Defender portal.
PIM was enabled for all Intune and Defender administrative roles. Standing privileged assignments were eliminated across the tenant.
Sprint 5 — General rollout and runbook handover
Policies were expanded from the pilot ring to early adopters, then general deployment, following the defined validation windows. Enforcement-phase Conditional Access was enabled after general deployment had been stable for 14 days.
A runbook was produced for each subsidiary's IT team covering: device enrolment procedures, compliance failure troubleshooting, MDE alert response workflow, and the process for requesting ring progression for new device groups.
By the end of the engagement, Intune compliance baseline coverage exceeded 90% of the managed device estate across all subsidiaries. The remaining 10% were factory floor devices operating under a documented exception policy with compensating controls.
Legacy AV products were fully replaced by Defender for Endpoint. The central security team had unified threat visibility across all subsidiaries for the first time — a single Defender XDR portal view covering the entire Körber estate, with subsidiary-scoped RBAC ensuring each local team could manage their own incidents without access to other subsidiaries' data.
MDO anti-phishing, Safe Links, and Safe Attachments significantly reduced the volume of malicious email reaching end users. Phishing simulation results in the month following deployment showed a 60% reduction in click-through rates compared to the pre-engagement baseline.
The runbook and admin training delivered at engagement close enabled subsidiary IT teams to independently maintain the configuration, reducing ongoing dependency on external consultancy for routine Intune and Defender administration.
The engagement gave Körber a practical way to standardise security without breaking subsidiary operating models. Central security gained cross-group visibility, local IT retained the autonomy needed to support business-specific endpoint populations, and exception handling for factory environments was brought into a documented governance model rather than being left as unmanaged drift.
This changed the economics of operating the platform. New subsidiaries, new device cohorts, and future security policy changes could be onboarded through the same ring-based rollout and RBAC structure, which reduced rollout friction and made the environment more supportable as the group continued to evolve.
Book a discovery call to discuss your Microsoft environment.