A Free Conditional Access Baseline for Microsoft 365

Microsoft reports that 99.9% of compromised accounts in its telemetry lacked multi-factor authentication, and Conditional Access is the policy engine that enforces it. Yet most small and mid-sized tenants we audit still run the default settings, or worse, a half-finished pilot from 2021. That gap is the single biggest reason ransomware crews still walk into Microsoft 365 environments through stolen passwords.

So here's the decision in front of you: build your own Conditional Access framework from scratch (weeks of work, real risk of locking yourself out), pay a consultant five figures to ship something custom, or deploy a vetted baseline and tune it to your business. We just released option three for free. The ConditionalAccessBaseline-Hardened repository on GitHub contains the exact policy set our engineers deploy for production clients, sanitized and ready to import.

This article walks through what's in the baseline, who it's for, what it costs you to skip it, and how to roll it out without breaking Monday morning logins.

Key Takeaways

• Our free Conditional Access baseline is published on GitHub and deployable in a single afternoon.
• The policy set blocks legacy authentication, enforces MFA, and isolates admin accounts by default.
• Break-glass accounts are pre-configured so you cannot lock yourself out of the tenant.
• Report-only mode lets you validate every rule against real sign-ins before enforcement.
• The baseline assumes Entra ID P1 minimum; some policies benefit from P2 risk signals.

What "Conditional Access" Actually Does

Conditional Access is the gatekeeper sitting between a user's sign-in attempt and the resource they're trying to reach. It evaluates signals (user, device, location, app, risk level) and decides: allow, allow with MFA, require a compliant device, or block. Think of it as a firewall for identity instead of network traffic.

Without it, Microsoft 365 trusts a valid username and password from anywhere on the planet. With a sensible policy set, an attacker who phishes a credential still hits a wall: unfamiliar device, unfamiliar country, unfamiliar app. That wall is what stops password-spray attacks from turning into full tenant takeovers.

The catch? Conditional Access is powerful enough to lock every user out of every app in about thirty seconds if you misconfigure it. That's why most IT teams either avoid it or deploy something so permissive it provides no real protection.

Why We Published the Baseline for Free

Three reasons, in plain terms.

First, the threat landscape doesn't care about your budget. A 12-person law firm in Lévis gets hit by the same Evilginx phishing kits that target Fortune 500s. Withholding a working policy set behind a paywall slows down defenders, not attackers.

Second, peer review makes security better. Publishing on GitHub means any engineer in Montreal, Toronto, or Berlin can read the JSON, file an issue, and push a pull request. We've already accepted fixes that improved the guest-access logic. A private baseline never gets that scrutiny.

Third, it's good business. Plenty of organizations will deploy the baseline themselves and never call us. Some will deploy it, hit a tuning question, and reach out for a few hours of help. A handful will read the repo, decide they want a managed partner, and ask about full cybersecurity services. All three outcomes are fine.

What's Inside the Repository

The baseline is a structured set of Conditional Access policies exported as JSON, plus a README that explains every decision. The current release covers seven policy categories (Source):

1. Baseline protection for all users, requiring MFA for any cloud app from any location.
2. Admin hardening, applying stricter controls to the nine privileged Entra roles that matter most.
3. Legacy authentication block, killing the protocols (IMAP, POP3, SMTP basic auth) attackers love.
4. Device compliance gates for sensitive apps, so unmanaged BYOD can't reach finance data.
5. Risk-based policies that trigger on Entra ID Protection signals (sign-in risk, user risk).
6. Guest and external user controls, scoping what B2B identities can actually do.
7. Token protection and session controls, including sign-in frequency for admins.

Each policy ships in report-only mode by default. That's deliberate. You import the set, watch real sign-ins flow through it for a week or two, fix anything that surprises you, then flip policies to "On" one by one.

The Break-Glass Account Pattern

The repo includes a documented pattern for break-glass accounts: two cloud-only admin identities, excluded from every Conditional Access policy, with 24+ character passwords stored offline. If something goes wrong (and at some point, it will), you sign in with break-glass, fix the policy, log out. We've used this pattern for over a hundred tenants without a single lockout incident.

If you skip this step, you're one bad policy away from calling Microsoft support at 2 a.m. Don't.

The Cost of Doing Nothing

Let's put numbers on the alternative. IBM's 2024 Cost of a Data Breach report pegs the average breach in Canada at $6.32 million, with credential-based intrusions among the most common vectors. For a small business, even a "small" ransomware event runs $50,000 to $250,000 once you count downtime, recovery, legal, and insurance deductibles.

Conditional Access doesn't prevent every breach. But it stops the cheap, automated attacks: password spraying, credential stuffing, OAuth consent phishing. Those represent the bulk of incident-response calls our team takes. Blocking them with a free baseline is the highest return-on-effort security control available to a Microsoft 365 tenant right now.

Compare that to the time investment. A competent admin can deploy the baseline in report-only mode in roughly four hours. Tuning takes another one to two weeks of passive observation. Total elapsed time to meaningful protection: about ten business days.

Deploying It: A Realistic Walkthrough

Here's how a deployment usually plays out for a 50-user tenant. Treat this as a checklist, not a substitute for reading the repo's README.

Step 1: Pre-Flight Check (30 minutes)

Confirm your licensing. The baseline assumes Entra ID P1 (included in Business Premium, M365 E3, and most education SKUs). Some risk-based policies need P2. Inventory your service accounts and shared mailboxes; these often need exclusions because they don't do MFA. Document any third-party apps using basic auth, because the baseline will block them.

Step 2: Create Break-Glass Accounts (45 minutes)

Two cloud-only Global Administrator accounts. Long random passwords. Stored in a sealed envelope in a physical safe, and in your password manager's emergency access vault. Test them. Then test them again.

Step 3: Import the Policies in Report-Only Mode (1 hour)

The repo includes a PowerShell script using the Microsoft Graph SDK to import every policy with the "Report-only" toggle set. Run it against your tenant. Verify in the Entra portal that all policies appear and none are enabled in enforcement mode.

Step 4: Observe for 7 to 14 Days

Open the Conditional Access "Insights and reporting" workbook daily. Look for sign-ins that would have been blocked. Each one is either a legitimate user you need to accommodate (add an exclusion or adjust the policy) or an attacker (good, the policy works). This is where the real work happens.

Step 5: Enforce Gradually

Flip policies from report-only to "On" in this order: legacy auth block first (lowest risk of false positives), then baseline MFA, then admin hardening, then device compliance, then risk-based. Wait 48 hours between each. If a help-desk ticket spike hits, roll back the most recent change and investigate.

Step 6: Document Exclusions

Every exclusion you add is a security debt. Track them in a spreadsheet with a review date. Service accounts should migrate to managed identities or workload identities within six months. Emergency exclusions for executives become permanent unless someone owns the cleanup.

If steps 4 through 6 sound like more than your team can absorb, that's exactly the kind of work our Microsoft 365 migration and security practice handles week in, week out.

When the Free Baseline Isn't Enough

The baseline is a strong starting point. It's not a finish line.

Industries with regulatory overlay (healthcare under PHIPA, financial services under OSFI, defence contractors under CMMC or ITAR) need additional controls: stricter device compliance, dedicated admin workstations, privileged access workstations, customer lockbox, and audit logging integrated into a SIEM. The baseline gives you 70 to 80 percent of what those frameworks require. The remaining 20 to 30 percent is industry-specific.

Multi-tenant environments, complex B2B partner networks, and organizations using Conditional Access for app governance (not just identity) will outgrow the baseline within a year. That's normal. The repo is meant as a launch pad, not a ceiling.

And of course, Conditional Access is one layer. You still need endpoint detection and response, email security, patch management, and tested backups. Identity protection without backup and recovery planning is a brittle defence. We've seen tenants survive credential compromise only to lose data to a ransomware affiliate who pivoted through a poorly secured file server.

How This Compares to Microsoft Security Defaults

Microsoft offers "Security Defaults" as a free, one-click protection setting, and Conditional Access "templates" for tenants with Entra ID P1. Both are useful. Neither is sufficient on their own.

Security Defaults enforce MFA but offer zero customization. You can't exclude a service account, scope by group, or apply different rules to admins. It's all or nothing, which is why most growing businesses outgrow it within a quarter.

Microsoft's built-in Conditional Access templates cover the basics but stop short of the harder calls: how aggressively to gate admin sessions, how to handle break-glass exclusions, what to do with B2B guests, when to require compliant devices versus hybrid join. Our baseline takes positions on each of those, documented in the README so you can disagree and modify.

Think of Security Defaults as a bicycle helmet, the templates as a motorcycle helmet, and a tuned baseline as full track gear. The right choice depends on how fast you're going.

What We Learned Building It

A few honest observations from production deployments.

Users notice the first week, then forget. Help-desk volume spikes for about five business days after enforcement, then drops below baseline. People adapt to MFA prompts faster than executives expect.

Legacy auth blocking always finds something. In every tenant we've deployed to, the legacy auth block surfaces at least one forgotten device, scanner, or line-of-business app still using basic SMTP. Better to find it on a Tuesday than during an audit.

Risk-based policies catch real attacks within weeks. On tenants with Entra ID P2, we typically see the first medium-risk sign-in blocked within 30 days of enforcement. These aren't theoretical threats; they're live credential-stuffing attempts against your users.

Documentation matters more than the policies themselves. Six months later, no one remembers why a specific exclusion exists. Future-you will thank present-you for the spreadsheet.

FAQ

Do I need an Entra ID P1 license to use the baseline?

Yes, at minimum. Conditional Access requires Entra ID P1, which is included in Microsoft 365 Business Premium, M365 E3, M365 E5, and several education SKUs. A handful of policies in the baseline (sign-in risk, user risk) require Entra ID P2. The README flags which policies need which tier.

Will deploying this break my users' sign-in experience?

Not if you follow the report-only rollout. Every policy ships disabled and in observation mode by default. You watch what would happen for a week or two, adjust exclusions, then enforce. Done correctly, end users see one extra MFA prompt for unfamiliar devices and nothing else changes.

Can I deploy this myself, or do I need a consultant?

A confident M365 admin who has worked with PowerShell and the Entra portal can deploy it solo. Plan for one full day of focused work plus two weeks of passive monitoring. If your team is stretched, or you want a second set of eyes on exclusions and break-glass setup, a few hours of consulting goes a long way. Our IT support team handles these engagements regularly.

Is the baseline maintained, or is it a one-time release?

It's maintained. Microsoft adds new Conditional Access conditions and grant controls every quarter, and the threat landscape shifts faster than that. We update the repository as new attack patterns emerge and as Microsoft ships new capabilities. Watch the repo on GitHub to get notifications.

What happens if I find a bug or want to suggest an improvement?

Open an issue or a pull request on the GitHub repository. We review submissions weekly. Past contributions from the community have already shaped the guest-access policy and the service account exclusion pattern.

Sources

• ConditionalAccessBaseline-Hardened on GitHub

A free baseline removes the excuse for leaving Microsoft 365 wide open. Pull the repo, read the README, and run the import script in a test tenant this week. If you'd rather have our team handle the deployment and tuning end-to-end, book a free IT assessment and we'll scope it on a 30-minute call.