A Passkey or Nothing
August 12, 2026 · InfraScout Team
Think about what an InfraScout session is actually worth to someone who steals one. Not a mailbox, not a file share — a console that can run commands across your Windows, Linux, and macOS hosts and read your Microsoft Cloud tenant through admin-consented permissions. Whoever holds a working session holds the assessment platform, and the assessment platform can see almost everything.
We have said before that InfraScout keeps no password of its own, and that your existing Conditional Access policies apply to it automatically. Both are true, and together they are a slightly uncomfortable statement: InfraScout is exactly as well protected as whatever policy you already had, which for most tenants means a push notification.
So we wrote down what we think that policy should be. There is now a Conditional Access hardening page in the docs with a six-policy baseline — the settings, the rollout order, the group structure, and the failure modes. This post is about the three decisions inside it that took actual thought.
The credential that can't be relayed
Ordinary multifactor authentication proves the user had a second factor. It does not prove they used it on the site they believed they were on. Modern phishing kits sit in the middle and relay the challenge in real time: the victim approves a genuine prompt, the attacker collects a genuine session. The second factor worked perfectly and changed nothing.
Phishing-resistant methods break that by binding the credential to the origin. A passkey, a FIDO2 security key, Windows Hello for Business, or certificate-based authentication cannot be replayed through a relay, because the relay is not the origin the credential was issued for. Entra ships this as the built-in Phishing-resistant MFA authentication strength, and the baseline requires it for every InfraScout sign-in.
Because InfraScout's portal and its MCP endpoint sign in through the same application in your tenant, that one policy covers both. Your dashboard users and every AI client anyone connects — Claude Code, Claude Desktop, anything else speaking MCP — arrive through the same front door and meet the same requirement. There is no separate policy to write for the AI side, and no gap where an MCP client authenticates more weakly than a browser.
The awkward one
Standard hardening guidance says to block device code flow, and the guidance is right. It is the cleanest phishing primitive Entra still supports: the attacker starts the flow, sends you a code, and asks you to enter it at a real Microsoft sign-in page. Nothing about that page looks wrong, because nothing about it is wrong. Even a passkey does not save you — you authenticate perfectly, to a flow somebody else initiated.
InfraScout's one-command installer uses device code flow. agent enroll auto signs you in with a code precisely so you do not have to copy tokens and identifiers onto a target host by hand, and that convenience is the whole reason the command exists.
We could have left that out of the guidance. Instead the baseline blocks device code flow tenant-wide and carves out a single named group for the people who deploy agents, excluded from the block and from the managed-device requirement it cannot satisfy. That exclusion is a real weakening and the page says so plainly: those accounts hold the InfraScout Admin role already, and inside the exclusion they are protected by phishing-resistant MFA and nothing else. Keep the group small, review it quarterly, alert on device code sign-ins, and use the token enrollment path for anything at volume — it involves no Entra sign-in at all and sidesteps the exception completely.
A security baseline that quietly omits the vendor's own inconvenient dependency is not a baseline. It is marketing.
The browser you forgot you had
The third decision is smaller and catches people out. Requiring a compliant or hybrid-joined device is the right control — phishing-resistant credentials stop credential theft, but not a session token lifted off a compromised laptop. Entra proves device state to the browser through a client certificate or the platform SSO broker, and not every browser presents it: Chrome needs the Microsoft Single Sign On extension, Edge needs a signed-in profile, Firefox needs its SSO policy set.
That is well-trodden ground for the portal. It is a trap for MCP, because an MCP client opens your default browser to sign in — which is not necessarily the browser your users normally work in, and not necessarily the one your device configuration was tested against. A device policy can pass every check in the portal and then block Claude Desktop on the same machine.
Test the MCP path explicitly before you enable that policy, not just the dashboard. It is the single most likely thing to surprise you.
Where policy stops
Conditional Access governs interactive Entra sign-ins, and a fair amount of what InfraScout does is not one. Enrolled agents authenticate with certificates over mutually authenticated TLS and are governed by enrollment and revocation instead. The identity sync and cloud data-collection apps authenticate as applications with no user present, so user-assigned policies never evaluate them. Service accounts behind agentic workflows never sign in at all — they are bounded by their Entra group scope and their disable switch.
Entra's token protection control does not reach third-party applications either, so it cannot bind an InfraScout token to a device today. Session limits and device requirements are the practical substitutes, and the docs page says which control covers which path in a single table. Knowing where a control stops is part of relying on it.
Start in report-only
Every policy on the page is written to be created in report-only mode first. Leave them for a week of normal use — including at least one agent enrollment and one MCP connection — and read the sign-in logs before you enforce anything. Report-only is the only honest way to find the dependency you forgot, and there is always one.
The full baseline, with settings tables and a rollout order, is at Hardening Sign-In with Conditional Access. The trust model it sits on top of is in Security Architecture. Questions, or a tenant where one of these policies does not fit? info@infrascout.cloud.