This isn’t a hypothetical. It’s the exact scenario playing out in IT Manager forums right now, and the answers range from “it’s fine, just use Conditional Access” to “good luck, we gave up and blocked everything.”
Here’s what actually works.
The Core Problem: Your Policy Tools Don’t Speak the Same Language
Microsoft’s ecosystem has a Windows-first bias baked into its DNA. Intune handles macOS and Linux, but “handles” is doing a lot of heavy lifting. The compliance checks are basic, the feature support lags, and the agent behavior differs enough between platforms that a policy that works on Windows can quietly fail on a MacBook without triggering any alerts.
The real issue isn’t the tools themselves, it’s the expectation that one policy definition can map cleanly across three operating systems with different security models, different enrollment mechanisms, and different browser behaviors. That expectation is wrong.
What Actually Works for Company-Issued Devices
For managed machines, the pattern that survives contact with reality looks like this:
Windows (Intune): Full enrollment with Entra Join. Compliance policies cover patching, BitLocker, LAPS, and local admin restrictions. Conditional Access requires compliant device for full app access. Chrome needs the Microsoft SSO extension installed or users get blocked on a company laptop, a detail that trips up more teams than it should. Firefox has a Windows SSO setting you can push via policy, but it’s not as seamless.
Mac (Kandji/Jamf): The brute-force approach is treating Macs like slightly more complicated Windows machines and forcing Edge or Chrome for M365 apps. This works, but it’s a ticket generator in disguise. The better path: use Kandji’s compliance integration with Entra ID to report compliance status, then scope your Conditional Access policies to accept that signal. The integration isn’t flawless, it requires the right agent version, proper certificate setup, and a solid understanding of how Kandji maps its compliance checks to Entra’s expectations, but it’s functionally reliable for most small teams.
Linux: Be honest about what you’re getting. Intune supports Ubuntu and RHEL with the Intune app plus Edge, but compliance is basic. The pragmatic approach during a pilot: treat Linux machines like personal devices (browser-only access) until you’ve validated the Intune agent behavior across your specific distros and versions.
The Personal Device Question: Browser-Only Isn’t a Cop-Out
The most controversial decision in this space: what do you do with personal computers? Block them entirely, or let people access M365 from a browser with restrictions?
Blocking everything is the safest approach and the easiest to implement. It’s also the one that generates the most shadow IT, because people will access work email through their personal devices regardless of what you say. The question is whether you want visibility into that access or not.
The middle path that most teams land on: Conditional Access with app-enforced restrictions on Exchange and SharePoint/OneDrive, scoped to unmanaged devices. This gives you web access with downloads blocked. A detail worth testing before you announce it: saving an attachment to OneDrive from Outlook Web Access typically still works, because it’s a cloud-to-cloud transfer rather than a file download. The commenters who’ve rolled this out confirm it works, but they also emphasize testing it with your specific browser versions before telling anyone.
The browser-specific caveats are where this gets messy. App-enforced restrictions work natively in Edge. In Chrome, Firefox, Safari, and Brave, you’re relying on how Microsoft’s web apps interpret the device signals, and the experience is inconsistent. One IT manager’s war story: Brave and Safari on Macs generated the most support tickets in their rollout. The workaround they landed on was telling Mac users to use Edge or Chrome for M365 apps, which, surprisingly, caused less friction than expected.
The Licensing Trap Nobody Warns You About
Here’s where the “one policy” fantasy hits the budget wall. Intune Plan 1 costs $8 per user per month standalone, but it’s already included in Microsoft 365 Business Premium ($22/user/month) and M365 E3/E5. If you’re on Business Standard ($14), you only get Basic Mobility and Security, a free MDM subset that manages iOS, Android, and Windows 10/11, but critically does not manage macOS or Linux.
So your Macs and Linux machines are either unmanaged or relying on third-party tools like Kandji, which means you’re maintaining policies in two different consoles, mapping compliance signals between them, and hoping the integration doesn’t break when either vendor updates their API.
Here’s the pricing reality check:
| Option | Price (per user/month) | What You Get |
|---|---|---|
| Intune Plan 1 (standalone) | $8 | Core MDM for Windows, macOS, iOS, Android, Linux |
| M365 Business Standard | $14 | Basic Mobility ONLY, no macOS/Linux management |
| M365 Business Premium | $22 | Intune Plan 1 + Defender for Business |
| M365 E3 | $39 | Intune Plan 1 + (from July 2026) Remote Help, Advanced Analytics |
| M365 E5 | $60 | Full Intune Suite capabilities |
The math for a 100-person company: upgrading from Business Standard to Business Premium costs an extra $800/month but gets you Intune Plan 1, Defender for Business, and a unified compliance signal for Windows machines. That’s often cheaper than maintaining separate MDM tools plus standalone Intune licenses.
For the Mac fleet, the calculus is different. Kandji (or Jamf) runs $12.50 per Mac per month, more than Intune Plan 1’s per-user cost for someone with multiple devices. But the Apple-specific management depth justifies the premium for most teams. The real cost is the integration complexity, not the subscription.
Where Multi-Platform Policy Enforcement Actually Breaks
The failures aren’t where you expect. Here’s what actually bites:
The “personal laptop enrolled as trusted device” loophole. If you only require Entra Join for compliance, anyone can join their personal laptop and suddenly have it treated as a corporate device. The fix: enrollment restrictions in Intune that block personally owned Windows devices, and use corporate identifiers to whitelist only purchased hardware. This is the piece most teams skip, and it’s the one that creates the credibility-killing security gap.
Shared mailbox and scanner accounts. When you flip on “require compliant device” with no exclusions, shared mailboxes and scanner accounts get blocked. The fix is exclusions, but identifying all of them requires audit, and the sign-in logs only show problems after users complain.
Break-glass accounts. The emergency admin accounts that bypass MFA and other restrictions need explicit exclusions from compliance policies. Forgetting this locks you out of your own tenant at the worst possible moment.
Report-only mode is non-negotiable. The advice from IT managers who’ve been through this: run your Conditional Access policies in report-only for a week or two, read the sign-in logs, identify what breaks, then flip to enforcement. This is the difference between a rollout that takes a week and one that takes a quarter of incident tickets.
What About the “One Policy” Ideal?
The honest answer: you can’t have literally one policy across Windows, macOS, and Linux with today’s tooling. What you can have is one policy framework with platform-specific enforcement layers:
- Identity layer: Entra ID handles authentication and device trust signals consistently.
- Compliance layer: Each platform has its own compliance requirements (BitLocker on Windows, FileVault on Mac, LUKS on Linux, all reported through Intune or third-party integration).
- Access layer: Conditional Access evaluates the signals and grants tiered access.
The key insight: your intent is one policy, but the implementation requires per-platform configuration. Teams that try to force identical policies across platforms end up with either broken Mac workflows or security gaps on Linux, usually both.
The Pragmatic Rollout Playbook
Based on what’s actually working for small teams:
- Start with enrollment restrictions. Block personal device enrollment. Use corporate identifiers. This is foundational.
- Deploy app-enforced restrictions for unmanaged devices. Get browser-only access with downloads blocked before you tackle managed device compliance.
- Run everything in report-only mode for two weeks. Read the sign-in logs. Fix what breaks. Then enforce.
- Treat Linux as browser-only during the pilot. The Intune Linux agent isn’t mature enough for full compliance enforcement, and the risk of breaking developer workflows is too high.
- Communicate the browser policy early. If you’re telling Mac users Edge or Chrome for M365, announce it before the rollout, not after the ticket flood.
For deeper considerations on how far to go with device monitoring, and where employee trust becomes the bigger risk than security gaps, the decision framework is surprisingly similar to the employee monitoring minefield. Your employees will tolerate restrictions they understand, they won’t tolerate surveillance they can’t see the purpose of.
The Bottom Line
The multi-platform M365 access problem doesn’t have a one-click solution because the platforms themselves aren’t equivalent. Windows, macOS, and Linux have different security models, different management ecosystems, and different user expectations. The teams that succeed aren’t the ones who find the perfect tool, they’re the ones who design a policy framework that accepts platform differences while maintaining consistent intent.
Start with enrollment restrictions and browser-only access for unmanaged devices. Run everything in report-only mode before enforcing. Test the Edge case (pun intended) with your actual browser mix. And remember: your users will forgive a slightly annoying policy if it works consistently. What they won’t forgive is a policy that blocks them differently on Tuesday than it did on Monday, depending on which machine they happened to open.