## TL;DR
Give the automation a device identity the policy can accept instead of weakening the policy for everyone: run the agent browser on a managed, compliant device or VM that reports its compliance correctly, or scope a narrow policy exception to the service account and the SOC portal only, paired with stronger account controls. Compliant device checks cannot tell a helpful agent from an unmanaged laptop, so the session is blocked honestly until the automation runs from a place the policy trusts.

```text
conditional access device compliance check blocked the agent browser session on the soc portal
```

## Use this when
- The triage agent browser session to the SOC or Defender portal is blocked by a device compliance requirement.
- Human analysts on managed devices reach the same portal fine.
- Sign-in logs for the agent account show a device compliance failure reason.

## Not for this skill when
- The agent account itself is blocked or lacks a licence. That is an account problem with different log reasons.
- All devices including managed ones fail compliance tenant wide. That is a compliance sync outage to fix in Intune first.

## Steps
1. Read the sign-in log detail for the blocked session and confirm the failing policy and the device state the portal saw. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the blocking policy and the reported device state are both named
2. Decide the compliant home for the automation: a managed VM or device dedicated to the agent, enrolled and reporting compliance. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: the chosen host is enrolled and shows compliant in the device list
3. Move or start the agent browser session on that host and sign in again, watching the log. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: the sign-in succeeds with the compliant device claim present
4. If a scoped exception is unavoidable, limit it to the service account, the one portal application, and a network location, and record the risk acceptance. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: any exception in the policy shows exactly those three scopes and nothing broader
5. Test that a sign-in for the same account from an unmanaged context is still blocked. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: the negative test is blocked, proving the general policy still holds

## Why it happens
Device compliance is a blunt and valuable signal: the portal asks whether this session comes from a device the organisation manages and can vouch for. Automation often runs from a container, a developer laptop, or a forgotten server, none of which can make that claim, so the block is the policy working. The professional fix is to house automation like a user, on managed infrastructure, and to treat broad exceptions for service accounts as the security debt they are.

## Variants and edge cases
### conditional access device compliance blocked agent browser soc portal
The exact block wording from the sign-in log.
### agent service account requires compliant device defender portal sign in
The service account variant.
### automation blocked by compliant device policy managed vm exception scope
The managed host and scoped exception variant.

Compatibility: Microsoft Entra Conditional Access device conditions, Intune compliance, Defender portal access.

Edge cases to check:
- Service accounts used by automation should still have MFA or certificate based protection appropriate to their sign-in type; a device exception is not a free pass.
- Review automation sign-in locations quarterly; an agent that suddenly signs in from a new place deserves the same suspicion as a user.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_6oa_OIwRz35v9_p5aSHamA