Hardening Sign-In with Conditional Access
InfraScout has no password of its own. Every person who reaches the portal or drives an assessment from an AI client arrives through a Microsoft Entra ID sign-in, which means the strength of InfraScout access is exactly the strength of the Entra policy in front of it — no more, and no less.
That deserves deliberate attention rather than inheritance from your tenant defaults. An InfraScout operator can run commands across your Windows, Linux, and macOS estate and read your Microsoft Cloud tenant through admin-consented permissions. An attacker who lands a working InfraScout session has not compromised one application; they have acquired a console onto everything InfraScout can see.
This page is a recommended Conditional Access baseline written specifically for InfraScout: what to create, what to set inside each policy, the order to enable them in, and the one place where InfraScout's own tooling collides with standard hardening advice. The goal throughout is phishing-resistant authentication — sign-in that cannot be replayed by someone who talked a user into approving it.
Licensing
Conditional Access requires Microsoft Entra ID P1. The risk-based policy at the end of this page (IS-06) additionally requires P2. Everything else works with P1.
What Conditional Access Actually Covers
Conditional Access governs interactive Entra sign-ins. Several things InfraScout does are not interactive Entra sign-ins, so before you write a single policy it is worth knowing which paths your work will reach and which it will not.
| Path | How it authenticates | Conditional Access |
|---|---|---|
| Web portal | Entra sign-in in the browser | Fully covered — grant, device, and session controls all apply |
| AI client over MCP | Entra sign-in in your default browser | Covered, with the device caveat in IS-02 |
agent enroll auto | Entra device code sign-in | Covered, but device-state controls cannot apply — see IS-05 |
agent enroll with a token | Single-use enrollment token, no Entra sign-in | Not covered |
| Enrolled agent at runtime | Mutually authenticated TLS certificate | Not covered |
| Identity sync and cloud data collection | Application credentials, no user present | Not covered by user policies — see what this does not protect |
| InfraScout service accounts | Headless identities inside InfraScout, never sign in | Not covered |
The important line in that table is the second one. The portal and the MCP endpoint sign in through the same InfraScout application in your tenant, so a single policy set governs both your dashboard users and every AI client anyone points at InfraScout. You do not need a separate policy for Claude Desktop, Claude Code, or any other MCP client — they all arrive through the same front door.
Before You Start
Get four things in place first, because the most common Conditional Access incident is a policy that works exactly as written and locks out the person who wrote it.
Create at least two emergency access accounts — cloud-only, excluded from every policy on this page, with credentials stored offline and sign-in alerting attached. Every policy below excludes them by group.
Register phishing-resistant methods before you enforce them. A passkey, a FIDO2 security key, Windows Hello for Business, or certificate-based authentication has to exist on an account before a policy can demand it. Roll registration out first, confirm coverage, and only then flip IS-01 to on. Because the policies here target the InfraScout application rather than your whole tenant, users can still complete registration with a Temporary Access Pass — a Temporary Access Pass satisfies ordinary MFA but never satisfies phishing-resistant MFA, so it is a bootstrapping tool, not a way in.
Turn off overlapping legacy settings. If Remember multifactor authentication on trusted devices is still enabled in your tenant, disable it before you configure sign-in frequency in IS-03. The two together produce prompts nobody can predict.
Create the groups the policy set references, so you can assign them rather than editing membership into each policy:
| Group | Purpose |
|---|---|
InfraScout Break Glass | Emergency access accounts, excluded from every policy |
InfraScout Users | Everyone holding any InfraScout app role |
InfraScout Agent Enrollment | The small set of Admin-role accounts that run agent enroll auto |
WARNING
Every policy on this page should be created in report-only mode, reviewed against real sign-ins for at least a few days, and only then enabled. Report-only shows you exactly who a policy would have blocked, which is the only honest way to find the dependency you forgot.
Selecting InfraScout in the Resource Picker
In Target resources → Resources, search for InfraScout and select every application the picker returns. Depending on how consent was granted in your tenant you may see more than one entry — select all of them rather than guessing which one a given sign-in records.
To confirm you targeted the right thing, sign in to the portal once and open Entra ID → Sign-in logs. The resource recorded on that sign-in is the one your policies must include. Repeat the check with an MCP client connected; both should resolve to InfraScout.
TIP
Conditional Access is additive to the sign-in gate you set during tenant onboarding. The Assignment required? switch decides who may sign in at all; Conditional Access decides under what conditions. Keep both.
The Recommended Policy Set
Six policies, in the order you should enable them. The first four are the baseline; the last two address specific exposures.
| ID | Policy | Tier | Effect |
|---|---|---|---|
| IS-01 | Require phishing-resistant MFA | Essential | Passkey, security key, Windows Hello, or certificate — nothing replayable |
| IS-02 | Require a managed device | Recommended | InfraScout only from compliant or hybrid-joined hardware |
| IS-03 | Bound the session | Recommended | Periodic reauthentication, no persistent browser cookie |
| IS-04 | Block external identities | Essential | Guests cannot reach InfraScout even if assigned a role |
| IS-05 | Block device code flow | Recommended | Closes the code-phishing path, with a scoped enrollment exception |
| IS-06 | Step up when risk appears | Optional (P2) | Reauthentication and blocking driven by Identity Protection |
IS-01: Require Phishing-Resistant MFA
This is the policy that matters most, and the one to get right before any of the others. Ordinary multifactor authentication — a push notification, a code from an authenticator app, an SMS — proves the user held a second factor, but not that they used it on the site they thought they were on. Adversary-in-the-middle phishing kits defeat all of it by relaying the challenge in real time. Phishing-resistant methods bind the credential to the origin, so a relayed challenge simply fails.
The built-in Phishing-resistant MFA authentication strength accepts a FIDO2 security key or passkey, Windows Hello for Business or a platform credential, and Entra certificate-based authentication at multifactor level. It accepts nothing else — no push, no code, no Temporary Access Pass.
| Setting | Value |
|---|---|
| Users — Include | InfraScout Users (or All users) |
| Users — Exclude | InfraScout Break Glass |
| Target resources | The InfraScout applications |
| Conditions | None |
| Grant | Require authentication strength → Phishing-resistant MFA |
| State | Report-only → On |
Two behaviors surprise people. Conditional Access is evaluated after first-factor authentication, so a user may still be asked for a password before being told to present a passkey — the policy restricts what completes the sign-in, not what starts it. And Require authentication strength cannot be combined with Require multifactor authentication in the same policy, because the built-in MFA strength already is that control. Pick the strength.
DANGER
Do not enable this policy until you have confirmed, per account, that a phishing-resistant method is registered. A user with only an authenticator app will be locked out of InfraScout the moment you turn it on.
IS-02: Require a Managed Device
Phishing-resistant credentials stop credential theft. They do not stop a session token lifted off a compromised laptop. Requiring a managed device means an InfraScout session can only originate from hardware you can inventory, patch, and wipe.
| Setting | Value |
|---|---|
| Users — Include | InfraScout Users |
| Users — Exclude | InfraScout Break Glass, InfraScout Agent Enrollment |
| Target resources | The InfraScout applications |
| Conditions | None |
| Grant | Require device to be marked as compliant or Require Microsoft Entra hybrid joined device — with Require one of the selected controls |
| State | Report-only → On |
The exclusion for InfraScout Agent Enrollment is not optional. A device code sign-in cannot present device state — the machine doing the authenticating is not the machine receiving the token — so agent enroll auto fails against this control rather than prompting for anything. Members of that group are covered by IS-01 and IS-05 instead.
Browsers need help here too. Entra identifies a device to the browser through a client certificate or the platform SSO broker, and not every browser presents it by default: Chrome needs the Microsoft Single Sign On extension or the CloudAPAuthEnabled policy, Edge needs the user signed in to the profile, and Firefox needs its SSO policy configured. This matters more for InfraScout than for most applications, because MCP clients open your default browser for sign-in — which may not be the browser your users normally sign in with. Test an MCP connection specifically before enabling this policy, not just the portal.
Not ready for managed devices?
Where a compliance program does not yet cover everyone who needs InfraScout, a named location condition restricting access to your corporate egress ranges is a weaker but real interim control. Treat it as a step toward IS-02, not a substitute — network location says nothing about the health of the machine.
IS-03: Bound the Session
An InfraScout session that never expires is a standing invitation. Sign-in frequency forces periodic reauthentication, and disabling persistent browser sessions means a cookie left on a machine does not survive the browser closing.
| Setting | Value |
|---|---|
| Users — Include | InfraScout Users |
| Users — Exclude | InfraScout Break Glass |
| Target resources | The InfraScout applications |
| Session | Sign-in frequency → Periodic reauthentication, 12 hours; Persistent browser session → Never persistent |
| State | Report-only → On |
Start at twelve hours and tighten with evidence. The tradeoff is specific to how InfraScout is used: MCP clients hold a refresh token and renew it silently, and sign-in frequency is what interrupts that renewal. Set it too short and operators find their AI client asking them to sign in again in the middle of an assessment. Twelve hours covers a working day; four hours is defensible for Admin-role accounts if you scope a second policy to them.
Avoid Every time for InfraScout. It is designed for resources that redirect on session expiry, and against an MCP client it produces reauthentication prompts frequently enough to train people into approving them without reading — which is precisely the habit IS-01 exists to break.
IS-04: Block External Identities
InfraScout access already requires an app role assignment, so a guest cannot wander in. This policy makes that structural rather than procedural: if someone assigns a role to a guest account by mistake, the sign-in still fails.
| Setting | Value |
|---|---|
| Users — Include | Guest or external users → all external user types |
| Users — Exclude | InfraScout Break Glass |
| Target resources | The InfraScout applications |
| Grant | Block access |
| State | Report-only → On |
If you deliberately give external consultants or a managed service provider access to InfraScout, invert this: rather than blocking, require the phishing-resistant strength from IS-01 for external users as well, and review your cross-tenant access settings so you know whether their MFA claim is being trusted from their home tenant or performed again in yours. Trusting a partner's MFA claim means trusting their authentication policy, which may be weaker than the one you just built.
IS-05: Block Device Code Flow, Except for Enrollment
Device code flow lets a device without a browser get a token by showing the user a code to enter elsewhere. It is also the cleanest phishing primitive Entra still supports: an attacker starts the flow, sends a target the code, and the target types it into a genuine Microsoft sign-in page. Nothing about the page looks wrong, because nothing about it is wrong. Microsoft's guidance is to get as close to a unilateral block as your dependencies allow.
InfraScout has exactly one such dependency. The one-command install, agent enroll auto, signs in with a device code — that is what lets you enroll a host without copying tokens and identifiers onto it by hand. Blocking device code flow tenant-wide without an exception disables that path.
| Setting | Value |
|---|---|
| Users — Include | All users |
| Users — Exclude | InfraScout Break Glass, InfraScout Agent Enrollment |
| Target resources | All resources, excluding Device Registration Service |
| Conditions | Authentication flows → Configure Yes → Device code flow |
| Grant | Block access |
| State | Report-only → On |
Target all resources rather than just InfraScout. Device code flow is a tenant-wide exposure, and a block scoped to one application leaves every other one open. The Device Registration Service exclusion is required whenever the policy targets all resources, or legitimate device registration breaks.
The exclusion group is where the residual risk lives, so keep it honest. Membership is a standing exclusion from both this policy and IS-02, which means those accounts are protected by phishing-resistant MFA and nothing else — and because agent enroll auto requires the InfraScout Admin role, they are privileged accounts to begin with. Three practices keep that manageable:
- Keep the group to the smallest number of people who actually deploy agents, and review its membership on a fixed quarterly cadence.
- Use the token enrollment path for volume work — image builds, scripted rollouts, anything unattended. It involves no Entra sign-in at all, so it sidesteps this exception entirely.
- Alert on device code sign-ins by members of the group, and on any device code sign-in elsewhere in the tenant. Filter the sign-in logs by Authentication protocol = Device code flow.
Tighter, if you can
If you have Privileged Identity Management, making InfraScout Agent Enrollment a PIM-managed group turns the standing exclusion into an on-demand one — members activate it for a few hours when they deploy agents and it lapses on its own. Same policy set, much smaller window.
IS-06: Step Up When Risk Appears
With Entra ID P2, Identity Protection scores each sign-in and each user, and Conditional Access can react. For a platform that reaches your whole estate, reacting is worth the licensing.
| Setting | Value |
|---|---|
| Users — Include | InfraScout Users |
| Users — Exclude | InfraScout Break Glass |
| Target resources | The InfraScout applications |
| Conditions | Sign-in risk → High, Medium |
| Grant | Require authentication strength → Phishing-resistant MFA |
| Session | Sign-in frequency → Every time |
| State | Report-only → On |
Pair it with a second policy on User risk → High that blocks access outright, or requires a secure password change before InfraScout becomes reachable again. Sign-in risk describes one suspicious authentication; user risk means Entra believes the account itself is compromised, and an account in that state should not be running commands on your servers while you investigate.
Rolling It Out
Order matters, because each policy narrows a different dimension and the failures look different.
- Roll out phishing-resistant credential registration and confirm coverage across everyone holding an InfraScout role.
- Create all six policies in report-only and leave them for a week of normal use, including at least one agent enrollment and one MCP client connection.
- Review Entra ID → Sign-in logs → Conditional Access for sign-ins each policy would have blocked. Every hit is either a dependency you missed or an account that needs remediation — resolve which before proceeding.
- Enable IS-01 and IS-04 first. These change what completes a sign-in, and their failures are self-explanatory to the user.
- Enable IS-03, then IS-02. Device policy produces the most confusing failures, so give it its own change window and test the MCP-client browser path explicitly.
- Enable IS-05 last, after confirming from the logs that no unexpected tooling in your tenant depends on device code flow.
- Add IS-06 once the baseline is stable.
Creating a Policy from PowerShell
The portal is the clearest place to build these the first time. Once you know the shape you want, Microsoft Graph PowerShell makes them repeatable across tenants. This creates IS-01 in report-only mode:
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess","Application.Read.All","Group.Read.All"
# Every InfraScout application consented in this tenant
$apps = (Get-MgServicePrincipal -Filter "startswith(displayName,'InfraScout')").AppId
# Groups referenced by the policy set
$breakGlass = (Get-MgGroup -Filter "displayName eq 'InfraScout Break Glass'").Id
$users = (Get-MgGroup -Filter "displayName eq 'InfraScout Users'").Id
# The built-in phishing-resistant authentication strength
$strength = (Invoke-MgGraphRequest -Method GET -Uri `
"https://graph.microsoft.com/beta/identity/conditionalAccess/authenticationStrength/policies?`$filter=policyType eq 'builtIn'").value |
Where-Object { $_.displayName -eq 'Phishing-resistant MFA' }
$policy = @{
displayName = 'IS-01 - InfraScout - require phishing-resistant MFA'
state = 'enabledForReportingButNotEnforced'
conditions = @{
users = @{ includeGroups = @($users); excludeGroups = @($breakGlass) }
applications = @{ includeApplications = $apps }
clientAppTypes = @('all')
}
grantControls = @{
operator = 'OR'
authenticationStrength = @{ id = $strength.id }
}
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $policyReview the result in the portal before changing state to enabled.
What Conditional Access Does Not Protect
Being clear about the edges of this control is part of using it well.
Agents are outside it entirely. An enrolled agent authenticates with a certificate over mutually authenticated TLS, not with an Entra identity, so no policy on this page touches it. Agent trust is managed through enrollment and revocation in the portal — see Security Architecture for that model.
Token enrollment bypasses it by design. The token path exists precisely for hosts where a browser sign-in is impractical. A one-time enrollment token is a credential in its own right: generate it when you are ready to use it, treat it as a secret in transit, and remember it is consumed on first use.
Application credentials are not user sign-ins. The identity sync app and the Microsoft Cloud data-collection app authenticate as applications with no user present, so nothing you assign to users ever evaluates them. Conditional Access for workload identities can reach them, but its most obvious condition — a named location — is the wrong tool here: InfraScout does not publish a fixed set of outbound addresses, so a location-bound policy would eventually block a legitimate connection rather than protect anything. Do not build one.
What does work for those two apps is unglamorous and effective. Their permissions are read-only, and the Entra connection page lists every one of them — review that list and confirm you are comfortable with it. Rotate their client secrets on a schedule you set rather than waiting for expiry. Watch Entra ID → Sign-in logs → Service principal sign-ins filtered to those two application IDs, so an unexpected caller or an unexpected volume surfaces. If you license workload identity risk, a policy that blocks those service principals on elevated risk applies without needing an address at all.
Service accounts never sign in. The headless identities behind agentic workflows exist only inside InfraScout and are scoped by Entra group membership, not by sign-in policy. Control them through their group scope and the disable switch.
Token protection does not apply. Entra's token protection control currently covers a specific set of Microsoft resources and does not extend to third-party applications, so it cannot be used to bind InfraScout tokens to a device. IS-02 and IS-03 are the practical substitutes.
Troubleshooting
A user with a passkey is still blocked by IS-01. The passkey was probably not used. If the sign-in started with a password and the session already satisfied a weaker method, Entra will not automatically re-prompt for the stronger one — the user needs to restart the sign-in, choose Sign-in options, and select the phishing-resistant method explicitly.
The portal works but an MCP client is blocked by IS-02. The MCP client opened a browser that cannot present device state. Confirm which browser is your default, then apply the matching configuration: the Microsoft Single Sign On extension for Chrome, a signed-in profile for Edge, or the SSO policy for Firefox.
agent enroll auto fails after enabling IS-05. Confirm the signing-in account is a member of InfraScout Agent Enrollment, that the group is excluded from both IS-05 and IS-02, and that Device Registration Service is excluded from IS-05's target resources.
A sign-in is blocked by IS-05 that was not a device code sign-in. Sessions that began with device code flow stay marked as such through subsequent refreshes. In the sign-in log entry, check Original transfer method in the activity details — if it reads device code flow, sign out fully and start a new session to clear the marking.
Users are prompted far more often than IS-03 specifies. Another reauthentication setting is competing with it. Confirm Remember multifactor authentication on trusted devices is disabled, and check for a second Conditional Access policy applying a shorter sign-in frequency to the same users — the most restrictive one wins.
Related Reading
Security Architecture
The trust model underneath InfraScout — agent identity, roles, visibility, and audit.
Onboard Your Tenant
Enable the InfraScout application in Entra ID and assign your first roles.