How Conditional Access actually works
Conditional Access is the policy engine that decides, at every sign-in, whether to allow access and on what terms. It is an "if this, then that" system. For each sign-in attempt, Entra ID looks at signals, who the user is and what groups and roles they hold, which application they are reaching, the device and whether it is compliant, the location and network, the client app, and the real-time and aggregated sign-in risk. It matches those signals against your policies and then applies access controls: allow, block, require multifactor authentication, require a compliant or hybrid-joined device, require phishing-resistant authentication strength, or apply session limits.
Done well, it is the single most powerful control in Microsoft 365. The catch is that protection only exists where a policy actually applies, and working that out across many overlapping policies, with their assignments and exclusions, is genuinely hard. Siemserva computes the effective result for every user and app, so you can see what your policies really do, not what you assume they do.
Every sign-in: signals in, the engine decides, a control applies. Siemserva computes that result for every user and app.
MFA is not an on/off switch
The most common misunderstanding in Microsoft 365 security is "we have MFA, so we are covered." Multifactor authentication is not a switch you flip for the tenant. It is delivered through Conditional Access policies (or legacy per-user MFA, or security defaults), and it only protects the sign-ins a policy actually reaches. That means you can have MFA "on" and still have real holes:
- Legacy authentication protocols that do not support MFA and quietly bypass it.
- Users, groups, or admins left in an exclusion that was never removed.
- Applications that fall outside the scope of the policy you thought covered them.
- A policy left in report-only mode, logging what it would have done but never enforcing it.
Each of these leaves an account reachable with a password alone, the exact condition attackers look for. Siemserva shows where MFA is genuinely enforced versus merely assumed, per user and per app, and ties each gap to a fix.
Passwordless and phishing-resistant authentication
Not all MFA is equal. SMS and voice codes can be phished or intercepted. The stronger direction is phishing-resistant, passwordless authentication: FIDO2 security keys, passkeys, Windows Hello for Business, and certificate-based authentication. Conditional Access ties this together with authentication strengths, so you can require phishing-resistant methods specifically for administrators, sensitive applications, or high-risk sign-ins, while allowing standard MFA elsewhere.
The gap most tenants have is that the strong methods are available but not actually required where they matter. Siemserva audits which authentication methods are registered and enabled, whether authentication-strength policies exist, and whether phishing-resistant authentication is required for privileged roles and your most sensitive apps, so passwordless is enforced, not just offered.
The other signals and controls that matter
Conditional Access is far more than MFA. These are the levers that turn it from a login prompt into real access governance, and each is a place a gap can hide. Siemserva evaluates all of them.
Require a compliant or hybrid-joined device, tying access back to your Intune posture so unmanaged devices cannot reach sensitive apps.
Use Identity Protection risk signals to step up or block risky sign-ins, so a leaked password alone is not enough.
Named locations and trusted networks shape policy, and are a common source of overly broad exclusions.
Sign-in frequency, persistent browser, and app-enforced restrictions limit what a session can do, not just whether it starts.
Why Conditional Access is so easy to get wrong
Conditional Access is the front door to Microsoft 365, and it is deceptively hard to reason about. A real tenant has many policies, each with its own assignments, exclusions, conditions, and grant or session controls, and they overlap. One excluded group, one app left out of scope, one policy stuck in report-only, and a user you believed was protected is signing in with nothing in the way.
Reading the policies one at a time will not tell you this. You have to compute what the whole set actually does, for every principal and every app, and then check it against what is really happening at sign-in. That is what Siemserva does.
How we evaluate it: three techniques, together
Most tools do one of these. Siemserva does all three and correlates them, which is why it catches gaps the others do not.
Every policy is evaluated against every user, group, role, application, and condition, not just read as text. The engine computes the effective result for each principal and app, accounting for how multiple policies, assignments, and exclusions combine.
It inspects exclusions, scope, and policy state to find who is left out: risky exclusions, principals and apps no enforced policy covers, and report-only policies that look protective but were never turned on.
It replays the last 14 days of real sign-ins against the policy set, so prediction meets reality: who actually got in outside policy, where legacy authentication slipped through, and which conditions never fired.
That third technique is powered by your logs. Siemserva reads your Entra ID sign-in logs, the unified audit log, and directory logs to confirm what the policy evaluation predicts, and to catch risky activity beyond Conditional Access. See the full Microsoft 365 log analysis.
The gaps point-in-time checkers miss
A snapshot of policy settings looks fine while these gaps sit underneath it. Siemserva surfaces each one, ranked by Severity, with the evidence and a recommended fix.
Users and apps that, after all assignments and exclusions, no enforced policy actually applies to.
Break-glass and temporary exclusions left in place long after the reason for them is gone.
Legacy auth protocols slipping through gaps in policy coverage, confirmed in the sign-in logs.
Policies left in report-only mode that give the appearance of protection without any enforcement.
Applications that fall outside the cloud-app scope of the policies meant to protect them.
Policies that interact in ways that weaken the intended control when they are evaluated together.
Deeper than a Conditional Access test suite
Open-source test frameworks like Maester are excellent, and they include Conditional Access checks: a fixed set of best-practice tests that pass or fail against your policies. That is genuinely useful, and Siemserva runs right alongside it. But a fixed test list can only ask the questions someone wrote in advance.
Siemserva goes further. Instead of checking policies against a checklist, it computes the effective Conditional Access result for every user, group, role, app, and condition, then replays 14 days of real sign-ins against it. That is how it finds the gaps a test cannot express: the specific principals no enforced policy covers, the exclusion that quietly defeats a control, the report-only policy that looks protective, the app outside scope. Then it ranks each gap by Severity, maps it to compliance, and hands you a validated fix, or lets your AI plan it.
Run both: keep your Maester tests, and bring Siemserva's evaluation engine and AI on top.
In the same scan, the same report, and queryable by AI
Conditional Access findings sit alongside your configuration, log, and CVE findings in one unified security model, ranked by Severity and mapped to the frameworks your auditors ask about. Each carries the evidence behind it and a recommended fix you review and apply.
Through the Senserva MCP, you can ask your AI in plain language: which users are not covered by any Conditional Access policy, where legacy authentication is still getting through, or which report-only policies should be enforced, and get an answer grounded in your real tenant, not a guess. See Claude and the MCP and Senserva Trustworthy AI.
Frequently asked questions
It is finding where your Conditional Access policies do not actually protect you: users and apps no enforced policy applies to, risky exclusions, legacy authentication that slips through, and report-only policies that were never turned on. Siemserva evaluates every policy against every user, app, and condition to surface these gaps.
Reading policies tells you what each one says. Siemserva computes what they actually do together, across every user, group, role, app, and condition, including how exclusions and overlaps interact, then confirms it against the last 14 days of real sign-ins. That catches gaps a policy-by-policy review cannot see.
No. It reads your tenant through Microsoft's APIs, read-only. It reports the gaps with the evidence and a recommended fix, and you review and apply any change yourself.
Yes. Report-only policies left in report-only mode are a common gap. Siemserva flags them, along with policies whose exclusions or scope mean they never apply to the users you expected.
See your Conditional Access gaps
Run the demo free, no registration, no access to your tenant, and see how the evaluation engine surfaces coverage gaps. Then register free to point it at your own tenant.
Download and go, free