How Intune MDM Certs Made Me Trust Device Identity Again

It was a muggy Thursday afternoon in Bengaluru, and I was knee-deep in a hybrid join mess. You know the kind—devices showing up in Intune but not in Entra ID, registry values giving me the silent treatment, and my audit logs looking like a Jackson Pollock painting. That’s when I stumbled across something that changed how I verify device identity: the hidden power of Intune MDM certificates.

Why I Chose This Setup

I’ve been managing Windows endpoints for over a decade, and if there’s one thing I’ve learned, it’s this: registry values lie. Or at least, they’re too easy to spoof. I needed a way to validate that a device was truly enrolled in my tenant—and not just faking it with a copied registry key or a renamed hostname.

That’s when I came across Ben Whitmore’s deep dive on how Microsoft Intune MDM certificates embed cryptographic identifiers—specifically, the MDM Device ID and Entra ID Tenant ID—inside their Object Identifiers (OIDs). These aren’t your average cert fields. They’re buried in byte arrays, unreadable at first glance, but once decoded? Pure gold.

Step-by-Step: How I Pulled the GUIDs from the Abyss

I tested this on a Surface Pro 7 running Windows 11 23H2, enrolled via Autopilot into Intune and Entra ID joined. Here’s how I got the real device identity:

1. Opened certmgr.msc and navigated to: Certificates (Local Computer) > Personal > Certificates Look for certs issued by Microsoft Intune MDM Device CA or MS-Organization-Access.
2. Inspected the certificate extensions. The magic OIDs are:
   • 1.2.840.113556.5.4 → MDM Device ID
   • 1.2.840.113556.5.14 → Entra ID Tenant ID
3. Exported the cert and used a PowerShell script from MSEndpointMgr’s GitHub called Get-TenantInformation.ps1.
4. Decoded the byte arrays. This part was wild:
   • For the MDM Device ID, you reverse the first 4 bytes, then the next two 2-byte chunks, and leave the last 6 bytes as-is.
   • For the Tenant ID, it’s a slightly different pattern—8 bytes at the end stay untouched.
   Example: Raw: 12 34 56 78 9A BC DE F0 12 34 56 78 90 AB CD EF GUID: 78563412-BC9A-F0DE-1234-567890ABCDEF
5. Validated the cert chain using certutil to ensure it was issued by Microsoft and not some rogue internal CA.

What Caught Me Off Guard

Not gonna lie, the first time I tried decoding the OID bytes manually, I got a GUID that looked like a cat walked across my keyboard. Turns out, the byte order is a mix of little-endian and big-endian—classic Microsoft curveball.

Also, I assumed all devices would have the same cert structure. Nope. Older devices enrolled before 2022 had different key storage providers and lacked TPM protection. That was a red flag for me in terms of device trust posture.

Workarounds and Lessons Learned

• If you’re not seeing the certs, check both the LocalMachine and CurrentUser stores.
• Use certutil -store my to list certs and grep for Intune or MS-Organization-Access.
• TPM-backed keys show up as Microsoft Platform Crypto Provider. If it says Software Key Storage Provider, you might want to re-enroll the device.

And here’s a pro tip: if you’re scripting this across a fleet, make sure your script runs with admin privileges. Otherwise, you’ll miss the private key info and TPM status.

Final Thoughts

This method gave me something I hadn’t felt in a while: confidence. Knowing that I can cryptographically verify a device’s identity and its tenant association—without relying on mutable registry values or WMI queries—feels like stepping into the future of endpoint trust.

It’s not just about compliance. It’s about knowing that when a device says “I belong to your tenant,” it’s not bluffing.

What About You?

Have you tried decoding these OIDs yourself? Did you run into weird byte order issues or certs missing entirely? I’d love to hear how others are using this in the wild—especially in hybrid or co-managed environments.

Drop your war stories in the comments. Let’s make device identity less of a guessing game.