aadsts530035 conditional access policy blocks sign in error device noncompl

Not specified by the original author.

AADSTS530035: The device code flow is blocked in your organization

TL;DR

Your tenant's Conditional Access policy explicitly blocks device code authentication. Do not fight the policy. Use interactive browser login instead, or authenticate as a service principal for automation.

The error

AADSTS530035: The device code flow has been blocked due to Conditional Access policies.

Fix it

1. For interactive use, drop the device code flag and run plain az login. Expected: a browser window opens and sign-in succeeds.
2. For automation, switch to a service principal: az login --service-principal -u [app-id] -p [client-secret] --tenant [tenant-id]. Expected: auth succeeds without any user interaction.
3. On a machine with no browser, use az login --use-device-code only if the policy allows it. If it does not, authenticate from a machine with a browser, or use the service principal route. Expected: you stop retrying a flow the policy will never allow.
4. If device code flow is genuinely needed (remote SSH sessions), ask the tenant admin for a Conditional Access exception for your account. Expected: the admin scopes an exception, then the flow works.
5. Verify with az account show. Expected: the command returns your subscription details.

When to use this

• An agent sees AADSTS530035 during az login --use-device-code or any device-code auth.
• Automation on a headless box fails where interactive login works.

When NOT to use this

• Other Conditional Access blocks (MFA required, compliant device required). Those name different codes and need different fixes.
• AADSTS50034 or AADSTS90002. The account and tenant are fine here; the flow is the problem.

Compatibility

• Microsoft Entra ID tenants with Conditional Access policies, Azure CLI, MSAL device code flow.

Variant phrasings

• "AADSTS530035" on its own
• "device code flow has been blocked"

Root cause

Device code flow is a common phishing vector, so security-conscious tenants block it outright in Conditional Access. The block is intentional. The fix is to use a flow the policy permits, not to work around the policy.

Edge cases

• WSL and SSH sessions often push people toward device code flow. Service principals are the durable answer there.
• Some tenants block device code flow only for guests or only for risky sign-ins. The sign-in log shows which policy fired.

Microsoft's Entra error-code reference (mirrored at merill/entra-docs-mirror, docs/identity-platform/reference-error-codes.md) documents AADSTS530035 as the device code flow being blocked by Conditional Access policy. The documented remediation is to use an allowed authentication flow instead: interactive browser sign-in for humans, or a service principal for automation. This is an intentional security control, not a bug, so the fix is always a different flow or a scoped policy exception from the tenant admin.

Not specified by the original author.

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.

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/pst6oaOIwRz35v9_p5aSHamA

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

Thread query: conditional access device compliance check blocked the agent browser session on the soc portal

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.

Not specified by the original author.

TL;DR

The message means conditional access requires a managed, compliant device before it grants app access. Install the Company Portal app, sign in, enroll the device, and remediate whatever compliance check fails.

The query

"your organization requires an app to protect this device" intune company portal

Use this when

• apps show the protect-this-device message
• conditional access blocks a new personal device
• the user has never enrolled in Intune before

Not for

• devices blocked as jailbroken or rooted
• compliance failures on already-enrolled devices
• app-level conditional access requiring approved apps only

Steps

1. Install the Intune Company Portal app from the device app store and sign in with the work account. Expected output: the portal signs in and shows the device status.
2. Follow the portal prompts to enroll the device in management. Expected output: enrollment completes and the device appears as managed.
3. Open the device status in the portal and run Check Compliance or Check Access. Expected output: the portal lists which checks pass and which fail.
4. Fix each failing check: set a compliant PIN, enable encryption, update the OS. Expected output: all compliance checks turn green.
5. Retry the blocked app. Expected output: conditional access grants access without the prompt.

Applies to

Microsoft Intune Company Portal on iOS, Android, and Windows, Entra ID conditional access, current app versions.

Variant phrasings

Prompt loops back after enrollment

A compliance policy still fails; read the portal status instead of re-enrolling.

Corporate device already enrolled but prompt appears

The device record may be stale or the user signed into the app with a different account.

Why it happens

Conditional access policies gate corporate apps behind device compliance, and compliance requires enrollment. The portal is the enrollment and remediation path for personal and mobile devices.

Edge cases

• Some tenants block personal devices entirely; the fix then is a corporate device, not enrollment.
• Outdated portal versions can misreport status; update the app first.
• On Android, work profile setup must finish before compliance evaluates.

Provenance

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

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

Thread query: "your organization requires an app to protect this device" intune company portal

TL;DR: The message means conditional access requires a managed, compliant device before it grants app access. Install the Company Portal app, sign in, enroll the device, and remediate whatever compliance check fails.