How to build an enterprise MDM from scratch: Part 3
Identity & Policy Framework - Who Gets Access and What Gets Enforced
The infrastructure and configuration-as-code are set up. The next step is a way for people to access the platform, and rules for what devices should do. Identity integration connects your MDM to your identity provider for admin access and device enrollment. Policy framework defines the security & IT baseline: what you enforce, what you monitor, and how you automate compliance. It’s combined because they're deeply linked. Your identity decisions affect policy scope. The policy decisions depend on knowing who's using each device.
Part A: Identity Integration
MDM platforms need identity integration at two levels:
Admin access - Who can log into the MDM console and make changes?
Device enrollment - How do devices authenticate during setup, and what user accounts get created?
Both matter because if you get admin access wrong, you're locked out of your own platform. Get enrollment wrong, and devices have the wrong user context.
Admin Access: SSO Integration
Running a separate username/password for your MDM platform is a bad idea. People reuse passwords. Offboarding is manual. There's no MFA unless you build it yourself. Connect your MDM to your identity provider for admin access.
Protocol choice: Most MDM platforms support SAML 2.0 and/or OIDC, both work. SAML is more common in enterprise IdPs. OIDC is more modern and often simpler to configure. Use whatever your IdP supports well.
Role mapping: MDM platforms typically have roles such as admin, maintainer, observer, etc. Map these to IdP groups. When someone joins the security team, they get added to the IdP group and automatically have MDM access. When they leave, access is revoked automatically.
Just-in-time provisioning: Users should be created in the MDM platform on first login, not pre-provisioned. This reduces maintenance and ensures access is tied to the IdP state.
Common Pitfalls
Forgetting a break-glass account: If SSO breaks (IdP outage, misconfiguration, certificate expiration), you need a way in. Some platforms support local admin accounts alongside SSO. Some provide API tokens that bypass SSO. Have a documented break-glass procedure.
Not testing SSO in GitOps: If you're using GitOps (Part 2), SSO configuration must be in your configuration files. If it's not, a GitOps apply might reset or delete your SSO setup. Test this before it surprises you.
Certificate expiration: SAML uses certificates that expire. Put a reminder in your calendar. Certificate expiration at 2 AM on a Saturday is a bad time to learn you forgot.
Device Enrollment Authentication
When a device enrolls in MDM, who's using it? For Automated Device Enrollment (ADE), where devices enroll automatically through Apple Business Manager or similar, you often want to authenticate the end user during setup. This ensures the right person is setting up the right device and creates the correct local user account.
ADE options
No authentication: Device enrolls, creates a generic local account, or prompts for account creation. Simple, but you don't know who's using the device until they log in somewhere else.
IdP authentication during enrollment: Device setup prompts for IdP credentials. The MDM platform validates against your identity provider and can use that identity to create the local account.
Authentication via separate flow: User authenticates on a different device (phone, web) and receives a code to enter during setup. More complex, but it works when you can't integrate IdP directly.
Recommendations
For most organizations, IdP authentication during enrollment is the right choice. It provides:
Verification that the person setting up the device is authorized in the org
Automatic local account creation with the correct username
Audit trail of who enrolled which device
The tradeoff here is complexity. You need to configure SAML or OIDC for enrollment separately from admin SSO (they're different integrations). The IdP authentication experience during device setup is minimal, a web view, not a full browser, so complex IdP flows might not work well. When a user authenticates during enrollment, the MDM creates a local account. What username does that account get? This depends on what attribute your IdP sends and how the MDM platform interprets it.
Common patterns:
Email prefix: user@company.com becomes “user”
Full email: user@company.com stays as “user@company.com”
Custom attribute: UPN, employee ID, or another attribute from your IdP
Why this matters: The local username affects home directory path, file permissions, and any scripts that reference the user. If some devices have john.smith and others have john.smith@company.com, automation breaks.
Recommendation: Decide on a consistent format before you start enrolling devices. Configure your IdP to send the right attribute. Test with a single device before rolling out widely.
Part B: Policy Framework
The identity tells you who's using the devices. The policy tells you what those devices should do. An MDM policy is typically a check that runs on devices and reports pass/fail. Some policies just report (monitoring). Some policies trigger actions when they fail (enforcement).
Building a Security Baseline
Don't start from scratch. Use an established framework and adapt it.
CIS Benchmarks: The Center for Internet Security publishes detailed benchmarks for macOS, Windows, and Linux. They're comprehensive, well-documented, and widely recognized by auditors.
Platform vendor guides: Apple, Microsoft, and others publish security guides for their platforms. Less prescriptive than CIS, but aligned with platform capabilities.
Industry frameworks: NIST, SOC 2, and ISO 27001 all have device security requirements. If you're pursuing compliance, start with those requirements.
The Adaptation Problem
These frameworks are comprehensive, perhaps too comprehensive for most organizations. CIS Benchmark for macOS has 100+ recommendations. Implementing all of them on day one would break user workflows, generate floods of support tickets, create alert fatigue when everything fails, and make the security team very unpopular. Start small, pick 10-20 policies that address real risks in your environment. Monitor them first. Understand your baseline and gradually expand.
Policies generally fall into a few categories:
Encryption: Full disk encryption enabled (FileVault, BitLocker). Encryption recovery key escrowed. This is table stakes, and generally, there's no good reason for a production device to have encryption disabled.
Access Controls: Screen lock enabled with a reasonable timeout. Firewall enabled. Remote login disabled (or restricted). Automatic login disabled. These prevent unauthorized physical access and reduce the attack surface.
System Integrity: System Integrity Protection enabled. Gatekeeper enabled (macOS). Secure Boot enabled. No unsigned kernel extensions. These prevent system-level tampering.
Software Management: Automatic updates enabled and no prohibited software installed. Antivirus/EDR running. These ensure devices have the necessary security tools and don't have known-bad software.
Custom to Your Environment: VPN client installation. Approved browser configuration. Company-specific security tools are present. These are organization-specific and depend on your requirements.
Monitoring vs Enforcement
Monitoring only: When a policy runs, reports pass/fail, but takes no action on failure. You see compliance status in dashboards.
Enforcement: A policy failure triggers an action: install missing software, change a setting, notify the user, or restrict access.
The Monitoring-First Approach
Don't jump to enforcement. Start with monitoring.
Understand your baseline: If 60% of devices fail a policy on day one, that's a signal that maybe the policy is too strict, maybe there's a deployment gap, maybe there's a legitimate exception. Enforcing immediately creates chaos.
Find edge cases: Some devices fail for valid reasons. The video editing team needs that kernel extension. The security researcher needs unsigned tools. Identify exceptions before enforcement blocks legitimate work.
Build trust: Users and IT leadership are more receptive to enforcement after they've seen monitoring data. "We've been tracking this for a month, 95% of devices comply, and we need to address the remaining 5%" is a better conversation than "surprise, we're blocking everyone who fails."
Graduating to Enforcement
Once monitoring shows that most devices comply, you've identified and handled exceptions, and stakeholders understand the policy, then you can enable enforcement.
Enforcement options vary by platform and policy:
Automatic remediation: MDM pushes a configuration profile to fix the issue
Software installation: MDM installs missing software
User notification: Alert the user to fix the issue themselves
Access restriction: Block device from resources until compliant
Match enforcement to specific severity. Disk encryption failure might warrant access restriction. Missing an optional tool might just need a notification.
Policy Automation
Policies are most valuable when they drive automation.
The Pattern: Policy fails → Automation triggers → Policy passes.
Example: Policy checks "Required security agent installed." Agent is missing. MDM automatically installs the agent. Next policy check passes.
Example: Policy checks "Disk encryption enabled." Encryption is disabled. MDM pushes a configuration profile enabling encryption. User is prompted for a password. Next policy check passes.
What Can Be Automated: Software installation, Configuration profile deployment, Script execution, and user notifications.
What Requires Human Action: Hardware issues, Complex software setups, Decisions that need user input, Anything that might disrupt active work. Design policies, knowing which category they fall into. A policy that fails and can't auto-remediate needs a clear path for manual resolution.
Common Policy Mistakes
Too many policies too fast: Start with 10-20 critical policies. Add more as you mature. 100 policies on day one creates noise, not security.
Enforcement without a monitoring period: Always monitor first. Always.
No exception process: Some devices legitimately can't comply. Have a documented process for exceptions — who approves them, how long they last, how they're tracked.
Ignoring policy failures: If a policy has 40% failure rate for months, either fix the root cause or reconsider the policy. Persistent failure becomes background noise.
Not reviewing policies periodically: Operating systems change. Threats change. Security tools change. Review your policy set quarterly. Remove obsolete policies. Add policies for new risks.
Bringing It Together
Identity and policy work together. Identity tells you who's using devices, and the policy tells you what state those devices should be in. Identity groups can determine which policies apply, and the policy failures can trigger identity-based actions (restrict access until compliant). Get identity right, and you know your fleet. Get policy right, and you control your fleet.
What's Next
In Part 4, I’ll cover the operational side: configuration profiles, team-based device management, software deployment, and the migration process when you're moving from a legacy MDM.
