Announcing ISDF – Intune Stateful Device Fingerprinting

Hero image generated by ChatGPT

This is a personal blog. All opinions are my own - not my employer’s.

Enjoying the content? If you value the time, effort, and resources invested in creating it, please consider supporting me on Ko-fi.

Earlier this year, I published OuttaTune – a deep dive into how Conditional Access (CA) depends on device-sourced metadata and the risks of trusting values that endpoints themselves can assert. While the community feedback was fantastic, one thing became clear: it wasn’t enough to point out the problem. We needed a working pattern to solve it.

Today, I’m releasing ISDF – Intune Stateful Device Fingerprinting, an open-source project designed to bridge that gap.

Why ISDF?

Conditional Access is the backbone of modern identity-driven security. But CA is only as strong as the signals it consumes. With OuttaTune, I showed that:

• Device properties can be locally manipulated.
• Policies built on those values can be bypassed or weakened.
• While we should always avoid granting local admin access on endpoints, in every business there will always be scenarios where it’s unavoidable. Even then, you should always assume breach - local privilege escalation is table-stakes for skilled attackers and script kiddies alike, there are simply too many 0-days and misconfigurations out there.

The conclusion was uncomfortable but unavoidable: we can’t fully trust device-reported attributes.

That’s where ISDF comes in. It introduces a layer of cloud-stamped metadata – device attributes that cannot be set or altered by the device itself, but instead are:

• Sourced from hardware-bound identifiers (TPM, vTPM, UEFI, BIOS).
• Sent securely to Azure using PKCS-based device auth.
• Written to Entra ID via a Logic App with Managed Identity.
• Evaluated by CA policies with no write path from the endpoint.

In short: ISDF moves Conditional Access from “what the device says about itself” to “what the cloud knows about the device.”

Architecture Overview

The design is intentionally cloud-native, built on Azure primitives most enterprises already use:

1. Enrollment – Device enrolls in Intune and receives a PKCS certificate via Cloud PKI.
2. Collection – A remediation script runs at enrollment (and periodically after), collecting hardware-rooted identifiers and device class.
3. Authentication – Using the PKCS cert, the device requests a token from Entra.
4. Ingestion – The script POSTs metadata + token to a Logic App endpoint.
5. Validation – The Logic App validates the token (signature, app ID, cert binding).
6. Stamping – Using Managed Identity, the Logic App writes trusted values into extension attributes on the device object.
7. Enforcement – Conditional Access evaluates those stamped attributes in policies.

Each layer removes trust from the endpoint and shifts it into the cloud.

Defence in Depth

A quick tour of the threat model and mitigations (pulled straight from the HLD docs here and here):

• On-device spoofing: Metadata sourced from TPM/vTPM/UEFI/BIOS; tampering requires physical or firmware manipulation. (in v1.0.0 ISDF is geared towards cloud PCs and so uses Instance MetaData Service in Azure)
• Token theft/replay: Tokens are, bound to certs, and app-specific.
• CA manipulation: Extension attributes are only writable via the Logic App’s Managed Identity.
• MITM interception: Even if HTTPS is intercepted, the private key never leaves the device.
• Logic App overreach: Scoped permissions (Directory.ReadWrite.All) follow least-privilege.

This isn’t about perfect security. It’s about building layers that require attackers to escalate effort, skill, and time.

Deployment Pieces

The repo includes everything needed to stand up ISDF in your tenant:

• Deployments

  • ARM and Bicep templates for Logic Apps and APIM.
  • OpenAPI + JSON specs for APIs.
  • Policy definitions like ISDF_Compliance_Cloud.json and APIM policy XML.

• Scripts

  • ISDFDetect.ps1 – detection tooling.
  • ISDF_PR_Detection.ps1 – proactive remediation checks.
  • ISDF_PR_Watchdog.ps1 – task scheduler integration.

• Docs

  • CloudSync.md – details for Logic App, APIM, and PKI integration.
  • LocalMode.md – offline/edge deployment scenarios.
  • Example metadata (IMDS JSON samples for DevBox, W365, AVD, DevTestLabs).

• SecOps Queries

  • KQL queries for compliance failures (isdf_find_deviceCompliance_failures.kql) and detailed investigation.

Here’s one of the compliance checks in action:

Detection and Monitoring

ISDF isn’t just about stamping trusted attributes – it also ships with tooling to detect drift and breakage:

• Intune compliance script integration.
• Watchdog scheduled tasks to spot missing metadata.
• KQL queries to hunt for non-compliant devices across large estates.
• Diagnostic outputs from the Logic App for operational insight.

This dual focus on prevention and detection is deliberate. You can enforce trust, but you should also watch for where trust fails.

A Nod to Colleagues

While I first mentioned IMDS (Azure Instance Metadata Service) in the OuttaTune write-up, I promptly forgot about it when building ISDF. Credit goes to James Murray for reminding me at exactly the right time - a nudge that unlocked a simpler, stronger design.

Sometimes security research isn’t about big discoveries, but about remembering the small things that make a big difference.

The Name (and the Joke)

At some point in development, staring at scripts at 1am, I realised:
ISDF reads as “IS D Fing?”

For once, it wasn’t a backronym. Just a happy accident – and it made me laugh enough to keep the name.

Screenshots and Walkthroughs

The repo is packed with visuals:

• Logic App runs and validations
  

• Company Portal compliance status
  

• Watchdog scheduled tasks
  

• Intune custom compliance configs
  

All of these can be slotted into your environment to see ISDF working end-to-end.

Try It Out

The initial release of ISDF is now available:
👉 GitHub Repository Link

Clone it, deploy it, and adapt it to your own security model. The repo includes docs, deployment templates, policies, and detection scripts to get you started quickly.

Closing Thoughts

With OuttaTune, the aim was to highlight a blind spot. With ISDF, the aim is to close it – using native Azure and Intune capabilities, with minimal extra moving parts.

This is not “finished.” It’s a first release. There will be refinements, simplifications, and new use cases. But it’s a concrete step towards moving trust out of the endpoint and into the cloud – where we can apply stronger controls and higher assurance.

I’m also abundantly aware that this still relies on Intune and so an admin on the device could mess with it - its designed to resist that as much as Intune allows but Intune remains largely in userland and while I would love to see it moved as much as possible into the kernel and ISDF-type fingerprinting and attestation delivered natively, ISDF is (in my admittedly biased opinion) a useful addition to your compliance controls.

As always: feedback, forks, and PRs are welcome.
I’m excited to see what the community does with ISDF.