ABT Blog

5 Conditional Access Rules Every Financial Institution Needs

Written by Justin Kirsch | Thu, Jan 22, 2026

Your Microsoft 365 tenant has a front door, and right now it's probably answering the same question it asked in 2019: "Do you have the password?" That's it. Password correct, come on in. Password wrong, try again.

For a financial institution holding borrower records, member account data, and wire transfer approvals, that single question is reckless. 84% of organizations experienced identity-related breaches in 2025. Credential abuse accounted for 22% of all breaches. Attackers don't break in anymore. They log in.

Conditional Access replaces that single question with a rapid-fire interrogation: Who is logging in? From where? On what device? At what risk level? Based on those answers, it grants access, blocks access, or demands additional proof.

Most financial institutions have Conditional Access available in their Microsoft 365 license. Few have configured it beyond the defaults. Here are the five Conditional Access best practices that separate institutions with real security from those running on false confidence.

What Conditional Access Does (And Why Defaults Aren't Enough)

Conditional Access is the policy engine inside Microsoft Entra ID that evaluates every sign-in attempt against a set of rules you define. Think of it as "if-then" logic applied to every login:

  • If the user is a Global Admin, then require phishing-resistant MFA.
  • If the device isn't marked compliant in Intune, then block access to SharePoint.
  • If the login originates from a country where you have no employees, then block it.

The problem: default settings are designed for compatibility, not for regulated financial services. Factory defaults on a router don't protect a network. Factory defaults on Conditional Access don't protect a tenant holding NPI.

For credit unions subject to NCUA examination, banks facing FFIEC audits, and mortgage companies under CFPB oversight, these automated enforcement rules aren't optional. They're the documented access controls that examiners expect to see.

Rule 1: Block Legacy Authentication Protocols

This is the single biggest backdoor in most Microsoft 365 tenants. Legacy authentication protocols (POP, IMAP, SMTP, and older Office clients) don't support Multi-Factor Authentication. If an attacker has a stolen password and your tenant allows legacy auth, they bypass MFA entirely.

That bears repeating: legacy authentication is an MFA bypass.

For financial institutions, the risk is amplified. Regulators expect layered authentication controls. An NCUA examiner finding active legacy auth protocols in your tenant will flag it as a material weakness. A cyber insurance underwriter will note it as a coverage gap.

The fix: Create a Conditional Access policy that blocks all legacy authentication protocols. This forces every sign-in through modern authentication, which supports MFA. Before enforcement, audit your environment for legacy dependencies. Older multifunction printers, line-of-business applications, and document management systems are common offenders. Identify them first, migrate or exclude them deliberately, then block everything else.

What's changing in 2026: Microsoft is closing a related loophole. Starting March 27, 2026, Entra ID will enforce Conditional Access policies on OIDC-only authentication requests that previously bypassed policies with resource exclusions. If you have policies targeting "All resources" with specific exclusions, those exclusions could previously be exploited. The March 2026 change closes that gap. Review your policies now to avoid surprises.

Rule 2: Require Managed and Compliant Devices

A valid username and password from a jailbroken tablet running a two-year-old OS version shouldn't unlock your SharePoint site containing loan files and member account records. Identity verification answers "who is logging in." Device compliance answers "should we trust what they're logging in from."

The fix: Enforce a rule requiring devices to be marked "Compliant" in Microsoft Intune before accessing corporate resources. If the device isn't managed by your IT team, it doesn't get access to sensitive data. For a deeper look at building risk-based device policies, see our guide on risk-based security with Microsoft Intune.

For BYOD environments common in mortgage lending and field banking, pair this with Mobile Application Management (MAM) policies. Employees can access company email on personal phones through managed apps like Outlook, with data containerization protecting corporate information without managing the whole device.

What's changing in 2026: The "Require approved client app" grant control is being retired by June 30, 2026. Organizations currently using this grant must transition to "Require approved client app OR Require app protection policy" before the deadline. If you're relying on app-level controls for BYOD, review your Conditional Access policies now.

Rule 3: Block Risky Sign-Ins with Identity Protection

A loan officer logs in from Denver at 9 AM. Fifteen minutes later, the same credentials attempt a login from Lagos. Unless teleportation has been invented, that's a compromised account.

Microsoft Entra ID Protection analyzes sign-in behavior and flags anomalies: impossible travel, logins from known botnet IPs, password spray attempts, and tokens accessed from unfamiliar locations. These signals feed directly into Conditional Access.

The fix: Create a policy that blocks or forces password reset for sign-ins flagged as "High Risk." Layer a separate policy requiring MFA for "Medium Risk" sign-ins. This uses Microsoft's threat intelligence to catch attacks you didn't know were happening.

For financial institutions processing wire transfers and ACH transactions, catching a compromised identity before it reaches banking applications is the difference between a near-miss and a six-figure loss. 72% of breaches involve exploitation of privileged credentials. Identity Protection is how you detect that exploitation in real time.

Rule 4: Geoblocking (Location-Based Restrictions)

If your institution operates in North America, your tenant has no business accepting login attempts from Russia, North Korea, or regions where you have zero employees. Every foreign login attempt is noise at best and an attack at worst.

The fix: Create Named Location policies. You can build an allow-list of countries where your employees work or a block-list of known threat-source regions. Geoblocking Conditional Access policies dramatically reduce your attack surface by filtering out geographic noise before it reaches your authentication layer.

A community bank with branches in three states, a credit union serving members across one region, or a mortgage company with loan officers in specific markets can all define their geographic perimeter and block everything outside it. The signal-to-noise ratio on your sign-in logs improves immediately.

Rule 5: Require MFA for Every Administrator Account (No Exceptions)

Global Admin accounts are the keys to the kingdom. A compromised Global Admin can exfiltrate data, disable security policies, create backdoor accounts, and erase audit logs. MFA enforcement for admin accounts is non-negotiable.

The common failure: "break glass" or service accounts with admin privileges that bypass MFA for convenience. One of those accounts gets compromised, and the attacker owns the tenant.

The fix: Enforce a policy requiring MFA for every privileged role. Global Admins, Exchange Admins, SharePoint Admins, Security Admins, and Intune Admins all need MFA with no exceptions. For the highest-privilege accounts, move beyond app-based MFA to phishing-resistant authentication like FIDO2 security keys or passkeys. Microsoft now supports synced passkeys in Entra ID, reducing sign-in time from an average of 24 seconds with passwords to 3 seconds with passkeys while eliminating phishing risk entirely.

Break-glass accounts should exist for emergency access but with heavy monitoring, alerting, and physical security around the credentials.

The Ecosystem Effect: Conditional Access Protects More Than Email

A common misconception: "We secured our email, so we're covered." But Microsoft 365 is a platform. A single identity unlocks Outlook, Teams, OneDrive, SharePoint, and potentially dozens of third-party applications connected through Single Sign-On.

For a mortgage company, that single identity accesses loan origination documents, borrower PII, and closing disclosures. For a credit union, it's member account data, internal audit reports, and board communications. A breach in one area is a breach in all areas.

Comprehensive Conditional Access rules in Microsoft 365 protect the entire ecosystem. Every application, every data store, every collaboration channel runs through the same policy engine. That's the difference between locking one door and securing the building.

Why Financial Institutions Hesitate (And Why They Shouldn't)

If these rules are so important, why do so many institutions leave the defaults in place? Two reasons:

Fear of disruption. One misconfigured block rule locks the CEO out of email during a board meeting. A legacy app breaks when you disable old authentication. Loan officers lose access to the LOS during rate-lock crunch time. The "scream test" is real, and IT teams choose the risk of a breach over the risk of disruption.

Complexity. Understanding how Grant and Block controls interact across different license types (Business Premium vs. E3/E5), how exclusions compound, and how to handle exceptions for legacy applications requires hands-on expertise that most internal IT teams haven't built.

Both of these problems disappear with proper planning. Report-only mode eliminates the scream test. A staged rollout with legacy app discovery prevents breakage. And a partner who's done this across hundreds of financial institutions knows where the mines are buried.

How ABT Implements Conditional Access Best Practices for Financial Institutions

ABT has spent 25+ years working inside the regulatory frameworks of banking, mortgage, and credit union compliance. Default settings don't satisfy NCUA, FFIEC, or CFPB oversight. That's why we built Guardian.

Guardian starts with Hardening where we configure these exact Conditional Access rules correctly the first time, identifying legacy dependencies and testing in report-only before enforcement. Guardian then moves to continuous Monitoring of sign-in anomalies, Insights that map to examiner expectations, and rapid Response when threats surface.

As a Tier-1 CSP serving 750+ financial institutions, ABT brings the expertise to implement Conditional Access best practices without the scream test. We know how to identify legacy apps before they break. We know how to configure exception policies that satisfy both operations and compliance. We turn the Microsoft cloud into a secure foundation so you can focus on serving members, borrowers, and depositors.

Talk to an ABT security expert to get your Conditional Access policies reviewed, or run a free Security Grade Assessment to see where your Microsoft 365 tenant stands today.

Frequently Asked Questions

Do I need to buy extra software to use Conditional Access in Microsoft 365?

No. Conditional Access is included in Microsoft 365 Business Premium, which is the standard license ABT recommends for financial institutions. Organizations on Business Standard or Basic are missing these security features. Upgrading to Business Premium is typically the first step ABT takes when onboarding a new institution.

Will enabling Conditional Access rules block remote employees from working?

Not when configured correctly. Conditional Access grants access when conditions are met, such as the correct user on a managed device from an approved location, and blocks access when conditions fail. ABT designs policies to support secure remote work at credit unions, banks, and mortgage companies without disrupting daily operations.

Why is MFA alone not enough to secure a Microsoft 365 tenant?

MFA is a strong control but it can be bypassed through legacy authentication protocols that don't support it, or worn down through MFA fatigue attacks where users blindly approve repeated prompts. Conditional Access acts as the decision engine that determines when to require MFA, when to block entirely, and when to force a password reset based on risk signals.

How does Conditional Access help with financial services regulatory compliance?

Conditional Access policies create documented, enforceable access controls that map directly to regulatory expectations from NCUA, FFIEC, and CFPB examiners. Each policy generates audit logs showing who accessed what resources, from which location, and on which device. This gives compliance teams evidence of systematic access governance during examinations.

What is the biggest risk of implementing Conditional Access without expert help?

The biggest risk is misconfiguration that locks out legitimate users, including executives, during critical business operations. A poorly scoped block rule can disable access for an entire department. Working with an experienced partner like ABT means policies are tested in report-only mode first, legacy dependencies are identified, and rollout happens in controlled stages.