Sensor Coverage, Phishing Results, and What's Worth Patching First
July 16, 2026 · InfraScout Team
InfraScout could already read a great deal about a Microsoft tenant's security posture. Reviewing what it could not read turned up three gaps with something in common: each one was a question an assessment reaches for early and had no way to answer.
Nine new read-only tools close them.
Is Defender for Identity actually watching?
Defender for Identity sees what its sensors watch. An unsensored domain controller is not a clean result — it is a blind spot that reads exactly like one, which is the worst property a security signal can have.
Two tools make that difference visible. One lists the sensor inventory across domain controllers, AD FS and AD CS servers, and Entra Connect hosts, with deployment status, health, service state, version, and a count of open issues per sensor. The other lists the health issues themselves: unreachable or outdated sensors, disabled auditing, certificate problems, connectivity failures.
The coverage check is a comparison rather than a read, and it is now one the AI can perform unaided: pull the sensor list, pull the domain controllers, and name the controllers that appear in one and not the other. That is the finding — not "sensor X is unhealthy", but "this controller has no sensor at all, so nothing here tells you what happens on it".
The health issues arrive with their remediation steps attached, including the PowerShell Microsoft supplies where it supplies any. A finding that comes with a fix is materially more useful than one that comes with a label.
What did your people actually do?
No amount of configuration review tells you how someone behaves when a credible lure lands in their inbox. Phishing simulation results do, and three tools now read them.
The first lists your simulation campaigns with the technique each used — credential harvesting, malware attachment, drive-by URL, link in attachment, link to a malware file, OAuth consent grant — along with status, timing, and training settings.
The second gives per-user outcomes for one campaign: who was compromised and when, who reported the message as phishing, the clicks and source IPs behind each outcome, and how much assigned training each person finished. This is what turns a compromise rate into a list of names.
The third reads tenant-wide coverage rather than one campaign, in three shapes. Per-user simulation counts, which is how you find the people who have never been included in any simulation — a gap that no per-campaign view can show you, because they are absent from all of them. Training assignment and completion. And repeat offenders: the users compromised across multiple campaigns, which is a different and more actionable population than the users compromised once.
One detail worth internalizing when reading these results: a null count is not a zero. Null means the person was never in a campaign. Zero means they were, and did not fall for it. Conflating the two would turn your least-tested users into your best-performing ones.
What is worth fixing first?
InfraScout could already ask a machine what was wrong with it. What it could not do was ask the organization.
Four tools cover the organizational view. The recommendation list is the risk-prioritized set behind the Vulnerability Management dashboard — per item, how many machines are exposed out of the total, whether a public exploit exists, whether an alert is already firing on it, and what fixing it would do to your scores. Those last fields are the ones that let a ranking be built on payoff rather than on severity labels.
The exposure score tool returns both organizational numbers together: the exposure score, where lower is better, and the Secure Score for Devices, which is an absolute point total. Two scales pointing the same direction, and reading them together avoids the obvious mistake. It can also break exposure down per machine group, which is how you find the one business unit dragging the tenant figure down.
Remediation activities are the follow-through check. Recommendations say what should happen; this says whether it did, with status, priority, and target-versus-fixed device counts. An empty list here is a legitimate answer rather than an error — it means no remediation tasks have ever been created, which is itself something to report.
And the software inventory gives the top-vulnerable-software view: weaknesses per product, exploit and alert flags, exposed machine counts, impact score. Pass one product's ID and it pivots to that product's CVE list with severity and CVSS scores. Two questions, one tool, in the order you would actually ask them.
Licensing, and what you do not need
None of this requires a Vulnerability Management add-on — Defender for Endpoint Plan 2 covers all four tools. The Defender for Identity tools need a deployed MDI workspace, and the attack simulation tools need Defender for Office 365 Plan 2. Microsoft 365 E5 includes everything. Where a license is missing, the tools return a clear message saying so rather than an ambiguous authorization error.
One thing to do before these work
These tools need permissions your tenant has not consented to yet. The onboarding script now grants 48 application permissions, up from 41 — the seven additions cover Defender for Identity health and sensors, attack simulation, and the four Vulnerability Management scopes.
Re-run create-infrascout-customer-app.ps1 in your own tenant. It is idempotent: it finds your existing app registration, re-applies the permission set, and leaves your secret alone if you tell it not to rotate one. Until you do, the new tools return an error naming the specific permission they are missing, so you will know exactly what happened.
Everything stays read-only and admin-consented. InfraScout still writes nothing to your directory or your cloud services.
Try it
Re-run the onboarding script, then ask the AI something these tools now answer — "which of our domain controllers have no Defender for Identity sensor?", or "who has never been included in a phishing simulation?", or "what are our top ten recommendations by exposure impact, and which have public exploits?"
Full reference in Microsoft Cloud — Security Tools. For the exposure graph tools that landed alongside these, see Following an Attack Path Backward. Questions? info@infrascout.cloud.