Conditional Access

Stop clicking around. Start hunting.

Kusto Query Language (KQL) Queries

Kusto Query Language (KQL) is the fastest way to slice through Microsoft Entra sign-in logs and find what matters. Instead of digging through endless menus, KQL gives you answers in seconds. Want to know why users are blocked? Determine whether a Conditional Access policy is causing chaos? KQL queries do the heavy lifting so you can focus on fixing problems, not hunting for them.

  • This query hunts for sign-ins that were flagged as medium or high risk during authentication but also where no conditonal access policy was applied. Risky sign-ins without enforcement are indicative of gaps in your security posture and conditional access coverage.

    The output of this query includes the timestamp, username, risk level at the time of the sign-in, and the IP address.

    SigninLogs
    | where RiskLevelDuringSignIn in ("high", "medium")
    | where ConditionalAccessStatus == "notApplied"
    | project TimeGenerated, UserPrincipalName, RiskLevelDuringSignIn, IPAddress

  • This query hunts for sign-in attempts from Microsoft Entra that were blocked by Conditional Access. It looks at the last 7 days, filters for error code 53003 (BlockedByConditionalAccess), adds a column to explain the failure reason, and returns the most useful fields for triage like timestamp, user, app, IP, location, and failure details. Results are sorted by the most recent failures first.

    SigninLogs
    | where TimeGenerated >= ago(7d)
    | where ResultType == 53003 or Status.errorCode == 53003
    | extend FailureReason = coalesce(Status.additionalDetails, Status.failureReason)
    | project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, Location = tostring(LocationDetails), ResultType, FailureReason
    | order by TimeGenerated desc

Dashboards

The Seven Pillars of Identity Protection

  • Why it slaps:
    Passwords alone are trash in today’s threat landscape. Attackers have credential dumps, phishing kits, and brute force tools that make single-factor authentication a joke. MFA is the single most effective way to stop account compromise dead in its tracks. Even if an attacker steals a password, they hit a brick wall. This is the foundation of Zero Trust and the first move every organization should make. If you are not enforcing MFA for all users, you are basically inviting attackers to your environment.

    How:
    Create a Conditional Access policy targeting All Users. Under Grant, require Multi-factor Authentication. Exclude only your break-glass emergency accounts so you do not lock yourself out during a crisis. No other exceptions. If a user cannot meet MFA requirements, they do not get in. Period.

    Why this is a damn good idea:
    Yes, this might require some user education and onboarding for MFA methods like Microsoft Authenticator, FIDO2 keys, or certificate-based authentication. But the payoff is massive: you instantly shut down credential-based attacks. Plus, modern MFA options like FIDO2 keys make sign-ins faster and more convenient than passwords. This is how you move security forward while making life easier for users.

  • Why it slaps:
    Admin portals are the crown jewels of your environment. If attackers get into Azure AD, Microsoft 365, or any privileged management console, it’s game over. Standard MFA is good, but modern phishing kits and token replay attacks can still bypass it. That’s why you need phishing-resistant authentication like FIDO2 security keys or certificate-based authentication. These methods kill credential phishing dead because they bind authentication to the device and origin, making it impossible for attackers to steal and reuse tokens. If you’re serious about Zero Trust, this is the next level.

    How:
    Create a Conditional Access policy targeting Directory roles (Global Admin, Privileged Role Admin, etc.). Under Cloud apps, select Microsoft Admin Portals (or specific apps like Azure Management and Microsoft 365 Admin Center). Under Grant, require Authentication strength set to Phishing-resistant MFA. This enforces FIDO2 or certificate-based authentication for every admin sign-in. No exceptions, no fallback to weaker MFA. If an admin can’t meet this requirement, they don’t get in. Period.

    Why this is a damn good idea:
    Yes, this move might require distributing FIDO2 keys or setting up PKI. But the payoff is massive: attackers can’t phish what they can’t replay. Plus, FIDO2 keys bring convenience with passwordless sign-ins that are faster and more secure than traditional MFA. This is how you move security forward while making life easier for admins. It’s a win-win.

    🔥 This policy is pure security muscle for your most sensitive entry points.

  • Why it slaps:
    When Entra ID flags a user as High Risk, it means something looks seriously off. These signals come from leaked credentials, impossible travel, and suspicious sign-in patterns. Allowing that account to keep operating is like leaving the vault door open during a robbery. The right move is to block access immediately and contain the blast radius. Break-glass accounts are the only exception because you need a way back in if things go sideways.

    How:
    Create a Conditional Access policy targeting All Users except your break-glass accounts. Under Conditions, set User risk level to High. Under Grant, choose Block access. No MFA fallback, no device compliance, no exceptions. The account stays blocked until your security team investigates and remediates.

    Important note:
    Yes, this could be a false positive. Machine learning is smart, but not perfect. That’s why the block is temporary and investigative. You’re not accusing the user of wrongdoing; you’re buying time to confirm the account’s state before letting it back in. This is Zero Trust done right: trust nothing until verified.

    🔥 This policy is about containment first, investigation and remediation second.

  • Why it slaps:
    Legacy authentication is the security equivalent of leaving your vault door wide open. POP and IMAP have been long dead and unsupported, but unfortunately some antiquated systems still cling to SMTP like it’s 1999. Attackers love these protocols because they completely bypass MFA, making password spray and brute force attacks stupidly easy. If you allow legacy auth, you are basically handing out free passes to your environment. Blocking it kills an entire class of attacks instantly.

    How:
    Create a Conditional Access policy targeting All Users. Under Conditions, select Client apps and choose Other clients to catch legacy protocols. Under Grant, choose Block access. No exceptions unless absolutely unavoidable for a critical legacy app. And if you must make an exception, follow other Zero Trust pillars: restrict the account to trusted locations, enforce strong monitoring, and plan for modernization.

    Why this is a damn good idea:
    Legacy auth is often still enabled on accounts due to historical misconfigurations, forgotten settings, or old service dependencies. Cleaning this up is not optional. Yes, it might require some remediation for SMTP-based workflows, but the payoff is massive: you eliminate one of the easiest attack paths in existence. Plus, modern authentication unlocks conveniences like passwordless sign-in and stronger security controls. This is how you move security forward while shutting the door on attackers.

    This policy is pure attack surface reduction. If you are not running it, you are leaving the barn door wide open for attackers using the oldest tricks in the book.

  • Why it slaps:
    Attackers love hiding behind foreign IP addresses. If your organization does not operate in a country, there is zero reason for sign-ins to originate from there. This is one of the simplest and most effective ways to enforce geographic Zero Trust. If you are not doing this, you are basically letting attackers knock on your door from anywhere in the world.

    How:
    Create a Conditional Access policy targeting All Users. Under Conditions, select Locations and define Named locations for the countries where your organization operates. Under Grant, choose Block access for all other locations. No exceptions unless absolutely unavoidable for a critical business need, and if you must allow it, pair it with other Zero Trust pillars like MFA and device compliance.

    Why this is a damn good idea:
    Yes, this might require some planning for remote workers or global travel scenarios, but the payoff is huge. You instantly cut off entire regions that attackers love to exploit. And here’s the kicker: this policy works beautifully when paired with other controls like MFA and risk-based sign-in policies. Together, they form a layered defense that slaps hard. This is how you move security forward while keeping attackers out of your backyard

  • Why it slaps:
    When Entra ID flags a user as High Risk, it means something looks seriously off. These signals come from leaked credentials, impossible travel, and suspicious sign-in patterns. Allowing that account to keep operating is like leaving the vault door open during a robbery. The right move is to block access immediately and contain the blast radius. Break-glass accounts are the only exception because you need a way back in if things go sideways.

    How:
    Create a Conditional Access policy targeting All Users except your break-glass accounts. Under Conditions, set User risk level to High. Under Grant, choose Block access. No MFA fallback, no device compliance, no exceptions. The account stays blocked until your security team investigates and remediates.

    Important note:
    Yes, this could be a false positive. Machine learning is smart, but not perfect. That’s why the block is temporary and investigative. You’re not accusing the user of wrongdoing; you’re buying time to confirm the account’s state before letting it back in. This is Zero Trust done right: trust nothing until verified.

  • Why it slaps:
    Let’s be real: service accounts that look and act like user accounts are a relic from the past. They exist because some legacy apps and crusty infrastructure still demand them. Is this best practice? Hell no. But if you absolutely must keep these accounts alive and they need MFA bypass to function, then locking them down to trusted IP ranges is non-negotiable. Without this, you’re basically leaving the keys under the doormat for attackers.


    How:
    Create a Conditional Access policy that targets these service accounts (use a dedicated security group for them). Under Conditions, set Locations to include only your trusted named locations like datacenter IPs or VPN ranges. Under Grant, allow access without MFA if required for legacy compatibility, but only from those safe zones. Everywhere else? Block it cold.