Konfirmity
Microsoft Intune logo

Secure your Microsoft Intune surface

Windows and mobile compliance policy state, BitLocker coverage, and devices marked compliant that are not. We don’t connect to Microsoft Intune to collect evidence for its own sake — we connect to secure it, and the compliance artefacts follow from that work.

Book a Demo

[01] What This Surface Exposes

Where Microsoft Intune goes wrong

Intune goes wrong through weak policy definitions: a device reports compliant because the policy never evaluated what you assumed it did.

  • Devices reporting compliant because a policy does not actually evaluate what you assume
  • BitLocker enabled without recovery keys escrowed to Entra ID
  • Compliance policies with grace periods long enough that non-compliance never blocks access
  • Personal devices enrolled with corporate access under weak conditions
  • Devices that have not checked in for long enough that their reported state is meaningless

[02] What We Secure

What we watch, catch and fix on Microsoft Intune

On Intune we audit what each compliance policy actually checks, because a weak policy produces a green dashboard and no security.

  • Compliance policy content audited, not just the compliant/non-compliant count, since a weak policy produces a green dashboard and no security
  • Recovery key escrow verified per device rather than assumed from the encryption flag
  • Grace period configuration surfaced, because a long grace period silently disables conditional access enforcement
  • Check-in recency tracked so stale device state is treated as unknown rather than good
  • Personal versus corporate device populations separated in reporting

[03] Where It Lands

Where Microsoft Intune lands in your registers

Every managed device becomes an asset register entry with its owner, encryption state, and OS currency. Access reviews cover the accounts bound to it, and the risk register carries what an unpatched or unencrypted endpoint actually exposes given the data that person handles. The gap that matters most is the device your MDM has never seen — we reconcile against your directory and HR record to find it.

[04] How We Engage

On Microsoft Intune specifically

On Microsoft Intune, we tighten compliance policy definitions and drive recovery key escrow. Conditional access coupling and reducing grace periods we stage carefully with you, since both can lock users out if rushed.

Platform licence

Everything you need to find and fix it yourself, with no ceiling on the depth of the answer.

  • Every connected tool monitored for misconfiguration and drift, with findings mapped to the assets and risks they affect
  • Remediation guidance that tells you what is wrong and exactly how to fix it — however deep or awkward the issue is. We are engineers running a security company, so the answer is the real one, not a link to vendor documentation
  • Assets, access reviews, and risk register populated from the tools themselves rather than from spreadsheets
  • Unlimited integrations and unlimited users, with anything missing built within two weeks

Managed service

Every tool you connect through Konfirmity comes under our care, with our team doing the work.

  • Continuous misconfiguration and drift monitoring across every connected tool, watched by our analysts rather than by a dashboard waiting for you
  • Incident response led by us, with containment coordinated with your team
  • Remediation performed directly wherever you have granted us the authority to act — and where we cannot act, we project-manage the fix to completion rather than handing you a ticket
  • Decision support on the tools themselves: where something is failing you on capability or costing more than it returns, we will tell you, and help you replace it

[05] Microsoft Intune FAQs

What Intune permissions does Konfirmity need?

Konfirmity needs graph API permissions DeviceManagementManagedDevices.Read.All and DeviceManagementConfiguration.Read.All. Those cover device state, compliance policy definitions and configuration profiles. Read is sufficient; write is requested separately only for agreed remediation.

Why check policy content rather than compliance counts?

Because the count is only as meaningful as the policy behind it. A compliance policy that checks little will report a healthy fleet indefinitely. We read the policy definitions themselves so a permissive rule is visible as the finding it is.

[06] Related Integrations

Other endpoint & device tools we secure:

View all integrations