M365 Sign‐In and Conditional Access Flow Simulator

M365 Sign-In and Conditional Access Flow Simulator

Overview

The M365 Sign-In and Conditional Access Flow Simulator is an interactive training and decision-support tool that models the Microsoft 365 sign-in journey from identity input through token issuance or access denial.

It is designed to help people understand how sign-in signals, Conditional Access controls, and endpoint/session posture interact in practice. Instead of showing policy settings in isolation, it shows policy outcomes stage by stage so users can see exactly where risk is reduced, where warnings remain, and where access is blocked.

Core Purpose

This simulation exists to answer three practical questions:

1. What happens in the sign-in pipeline when specific risks appear?
2. Which controls make the biggest difference for a given threat pattern?
3. Where are the remaining gaps after policy is applied?

It is built for security awareness, architecture validation, and communication between technical and non-technical stakeholders.

What It Simulates

The simulator models five phases and seven execution stages:

• Phase 1: Identity input
• Phase 2: Password validation
• Phase 3: Multi-factor challenge
• Phase 4: Conditional Access evaluation
• Phase 5: Session protection

Detailed stage path:

1. Username and tenant request
2. Password entry
3. MFA prompt selection
4. MFA verification
5. Conditional Access decision
6. Device and session checks
7. Access granted or denied

Each stage produces one of these outcomes:

• pass
• warn
• block
• not applicable

Input Model

The simulation combines four major input groups before each run.

1. Scenario selection

Scenarios represent specific sign-in and attack patterns, including:

• Standard workday sign-in
• Password phishing
• Unfamiliar location
• Device compliance failure
• MFA fatigue
• Legacy authentication
• Impossible travel
• Multiple MITM-style variants
• OAuth illicit consent
• Session cookie theft
• Admin and guest-focused edge cases

Each scenario carries seed conditions such as password correctness, sign-in risk, user risk, guest/member type, location, device compliance, auth protocol, MFA method, trust network context, and special threat flags.

2. Security profile

Profiles map to predefined control bundles:

• Baseline
• Balanced
• Secure
• Microsoft recommended CA policies
• ASD recommended CA policies
• Legacy/weak
• Custom

When Custom is selected, individual control toggles become editable.

3. Client type

Client context modifies endpoint assumptions:

• Browser
• Mobile app
• Managed Windows device
• Managed Mac device
• Unmanaged device

Client type influences compliance assumptions, unknown platform handling, and browser assurance behavior.

4. What-If overrides

A What-If panel can override scenario defaults with explicit runtime values such as:

• IP and country
• User type and role
• Sign-in risk and user risk
• Device state and registration state
• Auth type (legacy/modern)
• MFA method
• Trusted network setting

An override diff panel shows exactly what changed between inherited scenario assumptions and effective runtime assumptions.

Policy and Control Model

The control surface combines Microsoft-style controls and ASD Blueprint-aligned controls.

Examples include:

• Require MFA
• Prefer phishing-resistant MFA
• Number matching
• Block legacy auth
• Require compliant devices
• Session protection
• Block unknown platforms
• App consent governance
• Block device code flow
• Token protection
• Admin- and guest-specific controls
• ASD policy family controls (ADM, DEV, GST, LOC, USR)

The simulator can therefore show outcomes under both common Microsoft guidance and ASD policy structure.

Decision Engine Operation

The decision engine runs in this order:

1. Start with scenario data.
2. Apply client-type overrides.
3. Apply What-If overrides (if enabled).
4. Resolve effective control settings from selected profile or custom toggles.
5. Evaluate each stage using deterministic rule logic.
6. Stop early if any stage blocks.
7. Calculate run summaries, findings, confidence indicators, and sign-in log artifacts.

Stage evaluation behavior

Each stage has explicit rule logic that maps effective context and controls to pass/warn/block.

Examples:

• Password stage blocks invalid password.
• MFA stages can warn or block based on method strength, suspicious push behavior, relay indicators, and policy requirements.
• Conditional stage considers legacy auth, risk signals, guest/admin posture, location, OAuth consent behavior, and mitigation controls.
• Device stage reflects compliance, registration, browser assurance, and session hardening controls.
• Access stage models terminal replay/cookie/session hardening outcomes.

Threat scoring behavior

A threat score is calculated and adjusted as stages complete.

• Initial risk is based on scenario + context factors.
• Each stage adds or reduces risk with stage-specific deltas.
• A visual meter displays rising, falling, or neutral movement.

Important: this score is heuristic and educational. It is not a replacement for Microsoft risk engine telemetry.

User-Facing Outputs

Each run produces multiple artifacts for analysis.

1. Stage-level visual trace

• Active stage highlighting
• Rule fired messages
• Stage status chips
• Progress meters
• "Show me why" evidence panels with contextual details and documentation links

2. Outcome cards

• Selected profile outcome
• Comparison against a reference profile
• Protection and exposure bars
• Stop point and pass/warn/block counts
• Control-difference narrative

3. Narrative and findings

• Story panel translating technical behavior to business-impact language
• Misconfiguration callouts identifying missing or weak controls
• Confidence panel showing signal quality and ambiguity factors

4. Event log timeline

A stage-by-stage log records simulation events and decisions in execution order.

5. Simulated sign-in log record

A structured simulated sign-in record is generated with fields such as:

• Correlation/request IDs
• User and external identity context
• App/client/device context
• Risk labels
• Authentication requirement and result type
• Conditional Access status
• Applied policy tags
• Raw JSON export

This record can be downloaded as JSON for sharing or lab exercises.

6. Share and reporting helpers

• Copy shareable link with encoded run state
• Copy run summary text
• Persistent run counters (total and session)
• Theme toggle with saved preference

7. Validation harness

A built-in matrix validator runs broad combinations across profiles, scenarios, clients, and custom control masks to verify logic consistency and detect rule regressions.

Practical Value Provided

Security awareness and training value

The simulator makes abstract identity security concepts tangible by turning policy into visible sign-in outcomes. Teams can see why certain controls matter instead of only being told they matter.

Policy design and tuning value

Architects can test how control combinations behave across normal and adversarial scenarios. This helps avoid both under-protection (missed blocks) and over-friction (unnecessary challenge paths).

Control prioritization value

By comparing selected posture versus a reference baseline, the tool highlights which control had the largest practical impact for a scenario. This supports sequencing and roadmap decisions.

MITM and replay education value

The scenario set explicitly includes modern attack paths (relay, token replay, cookie theft, consent abuse). This helps teams understand where MFA alone is insufficient and where session/token controls are required.

Guest and privileged identity governance value

Separate behaviors for guest and admin contexts help teams reason about differentiated trust and stronger requirements for high-impact identities.

Documentation and communication value

The narrative, evidence, and generated run summaries make it easier to explain security posture decisions to leadership, auditors, and cross-functional stakeholders.

Testing and quality value

The integrated validation sweep provides an internal quality check against rule drift and inconsistent logic when controls or scenarios evolve.

Recommended Usage Pattern

1. Start with a baseline scenario and Balanced or Secure profile.
2. Run and review stage outcomes, misconfig callouts, and confidence indicators.
3. Toggle one control at a time in Custom mode to observe specific impact.
4. Use What-If to test edge conditions (country, role, auth type, device state).
5. Compare to a stronger reference profile to identify the most meaningful uplift.
6. Export summary and sign-in log record for decision notes or training material.

Scope and Limitations

This simulator is intentionally educational and deterministic.

• It does not call live Microsoft APIs.
• It does not implement real-time Entra analytics or production policy evaluation.
• Threat scoring is simplified and illustrative.
• Results should be used for learning, design discussion, and hypothesis testing, not as final production policy proof.

Use it as a safe experimentation and explanation layer alongside real tenant policy testing, sign-in logs, and security monitoring.

Bottom Line

The simulator provides high value because it bridges the gap between policy settings and observed identity security behavior. It explains not only what happened in a sign-in, but why it happened, what risk remained, and which control change would matter most next.