TL;DR — what owners actually want to know
- MFA is the cheapest control you can buy. If it isn't on every account, including the owner's, nothing else matters yet.
- Conditional Access is the bouncer that decides which sign-ins get extra scrutiny. It's how MFA stops being annoying for normal staff.
- Most M365 breaches start with a believable phishing email and end with a hidden inbox rule that quietly steals invoice payments.
- Cyber insurance now expects MFA, blocked legacy authentication, an incident response plan, tested backups, and a working email-anti-spoofing setup.
- If you can't answer the last question on this page, you have a project, not a security program.
This FAQ is for the people who keep getting cc'd on security emails without a translator. Owners. Office managers. Controllers. Folks who run finance or operations and have to sign off on something that says "Conditional Access policy" without knowing what the words actually mean. You're not the IT person, and you don't need to become one. You do need to know enough to ask the right question and recognize a useful answer when you hear it.
Each question below opens with a one-sentence definition in plain English, gives a concrete example, and ends with what to ask your IT (or your IT vendor) so you can verify it's actually working. Skim or read straight through. If something is missing that would help you, the contact form at the bottom goes to a human.
Identity basics
1. What is MFA, and why does my IT keep asking about it?
MFA stands for multi-factor authentication. It means proving who you are with two things instead of one: your password, plus a code or tap on your phone.
The reason IT keeps asking is that passwords alone get stolen all the time. Phishing emails, breached websites, sticky notes on monitors, password reuse across personal sites. Once a password is out there, anyone in the world can try it against your work account. MFA stops that cold because the attacker would also need your phone in their hand.
A real example: in 2024 a controller at a 40-person engineering firm reused her password from a hobby forum that got breached. An attacker tried it against the company's M365 sign-in. With MFA off, the attacker would have walked in. With MFA on, the attacker got the password right and got stopped at the second factor. The whole event showed up as a single failed login.
Most cyber insurance policies now require MFA on every account, and the few minutes of training your staff need is the cheapest security control you will ever buy. Ask your IT: is MFA turned on for every single user, including the bookkeeper and the seasonal hire who started last week?
2. What's the difference between MFA on email and MFA on everything?
When IT first turns MFA on, it usually only triggers when someone logs into webmail in a browser. The Outlook app on a phone, the file-sharing apps, the calendar, the Teams meetings: those can sometimes connect with just a password and never ask for the second step.
That partial coverage is where most breaches happen. Attackers know to try the older mail protocols and side doors that skip the MFA prompt. Microsoft makes this easy to overlook because they ship a feature called Security Defaults, which is a basic on/off toggle that does some of MFA but not all of it.
Real protection means MFA covers every Microsoft 365 sign-in, on every device, every app, every protocol. The way to get there is a Conditional Access policy targeting "all cloud apps" with MFA required, plus the legacy authentication block we cover in question 6. Ask your IT: are we using Conditional Access to require MFA on all cloud apps, or did we just turn on the basic Security Defaults toggle?
3. What is Conditional Access?
Think of Conditional Access as the bouncer at the door of your Microsoft 365 tenant.
A bouncer does not check ID for everybody the same way. If you walk in wearing the staff uniform from the office down the street, you get waved through. If you show up at 3 a.m. from a city the bouncer has never seen, you get asked for ID, and maybe a second form of ID. Conditional Access works the same way. It looks at where the sign-in is coming from, what device, what time, and how risky it looks.
A normal sign-in from your office laptop sails through. A sign-in attempt from Russia at 2 a.m. gets blocked, or asked for an extra MFA challenge. A sign-in from a new phone the user has never used before? Maybe it asks them to verify by tapping their old phone first.
The point is: not every login is equal, and the rules can be tightened where the risk is highest without nagging your staff every five minutes. Ask your IT: can you show me the list of Conditional Access policies we have, what each one does in plain language, and which users are excluded from each?
4. What's a "break-glass account" and why do I need one?
A break-glass account is the spare key under the doormat for your Microsoft 365 tenant.
It is one or two admin accounts that are never used day-to-day, never enrolled in MFA on the same phone as everyone else, and stored somewhere physically secure. A sealed envelope in a locked safe is a common pattern. The username is something nobody would guess. The password is long and randomly generated, written down once, and never typed into a phishable browser.
The reason is simple. If your IT person is on a plane, their phone dies, the MFA app fails, and your Conditional Access rule accidentally locks every admin out of your tenant, you need a way back in. Without a break-glass account you have to call Microsoft support and prove ownership, which takes days. While you wait, nobody can fix the broken policy, reset other accounts, or respond to an active attack.
Ask your IT: do we have a documented break-glass procedure, who has access to it, and when was it last tested? "Last tested" is the part most companies skip.
5. What's the difference between Entra ID, Azure AD, and Active Directory?
These three names cause more confusion than almost anything else in the Microsoft world.
Active Directory is the old on-premises system from the 1990s. If your business has a server room with a domain controller in it, that is Active Directory. It manages the Windows logins on your office network.
Azure AD was the cloud version Microsoft launched to handle Microsoft 365 sign-ins. It is the system that decides whether a user is allowed into Outlook, Teams, SharePoint, and the rest of the M365 stack.
In late 2023 Microsoft renamed Azure AD to Microsoft Entra ID. Same product, new name. So if your IT says Azure AD or Entra ID, they mean the cloud identity system that controls every Microsoft 365 login: who can sign in, what they can access, and what the MFA rules are.
Most small businesses today only have Entra ID; they never had the on-premises server in the first place. The renaming caused a lot of older blog posts to look out of date even though the underlying concepts are unchanged. Ask your IT: just confirm whether we have on-premises Active Directory in the picture, or only Entra ID. The answer changes which security controls apply.
Email security
6. What does "blocking legacy authentication" actually mean?
Microsoft 365 still accepts logins through old email protocols from the 1990s: POP3, IMAP, SMTP AUTH, and a handful of others. Those protocols were invented before MFA existed, and there is literally no place in them to insert a second factor.
So when an attacker uses one of these old protocols, they only need a username and password to get in. Your MFA never fires. The attacker can run a list of stolen passwords against your tenant for hours, and the only sign in your sign-in logs will be successful or failed logins under "Other clients."
Blocking legacy authentication means flipping a switch in Microsoft 365 so those old protocols stop working entirely. Modern Outlook on a current phone or laptop does not need them. The only things still using legacy auth are usually a forgotten copier, a 2014 phone system, or some custom script nobody remembers writing. Once those are dealt with, the block is safe to flip on.
The full mechanics, the eleven specific protocols, and the rollout sequence are in our companion post on how to block legacy authentication in Microsoft 365. Ask your IT: is legacy auth blocked at both the Conditional Access layer and the Exchange Online policy layer? "Both" is the right answer.
7. What's a phishing email and why do they still get through?
A phishing email is a fake message designed to look like it came from a brand or person you trust, with the goal of getting you to click a link, download a file, or hand over your password.
The classic example is the Wells Fargo email asking you to verify your account. Or the FedEx tracking notice with a link that does not actually go to FedEx. The newer version is a message that looks exactly like Microsoft asking you to re-authenticate because your mailbox is full. You click, you see what looks like the real Microsoft login page, you type your password, you approve the MFA prompt because the page asked you to, and the attacker is now signed in as you.
The reason these still get through is that filters block the obvious junk, but a well-crafted spear phishing email aimed at one person at your company is hard to catch. The attacker may have read your LinkedIn, copied your CEO's signature, and timed the message for a Friday afternoon. Filters look at patterns. A one-off targeted message has no pattern.
The realistic defense is layered: good filters, plus DMARC and DKIM (so other companies' filters trust your domain), plus staff who pause before clicking and verify any payment change by phone. Ask your IT: what email filtering product do we use, and what's our process when a user reports a phishing message?
8. What is DMARC and do I really need it?
DMARC is a public note you publish about your email domain that tells the rest of the internet how to handle messages claiming to be from you.
The note basically says: "If a message claims to be from [email protected] but it didn't actually come from our real mail servers, throw it in the spam folder, or just delete it." Without DMARC, anyone in the world can send an email that looks like it came from your CEO, and the receiving company has no way to verify it.
Yes, you really need it. Three reasons. Major mail providers (Google and Yahoo) now reject or quarantine bulk email from domains without DMARC, so your real marketing emails start landing in spam. Your customers and vendors are more likely to trust your invoices and replies. And it dramatically reduces the chance someone successfully impersonates your domain to defraud a customer.
The setup itself is not hard for anyone with DNS access. The wait is on the policy: most companies start with a "monitor only" mode for 30 to 60 days to make sure they aren't blocking legitimate mail, then tighten to quarantine or reject. Ask your IT: is DMARC published, and is it set to p=quarantine or p=reject, not just p=none?
9. Why does my carrier ask if we have anti-spoofing?
When your insurance carrier asks about anti-spoofing, they are mostly asking about three specific email standards: SPF, DKIM, and DMARC.
Together those three tell the world's mail systems which servers are allowed to send mail as your domain, and what to do with messages that fail the check. SPF says "these servers are allowed." DKIM signs each message so the recipient can verify it wasn't tampered with. DMARC ties the two together and says what to do when something looks off.
Carriers ask because impersonation fraud is one of their biggest claim categories. An attacker pretends to be your CFO, emails the controller, asks for a wire transfer, and the money is gone before lunch. If your domain has the three standards configured correctly, the fake message often gets caught at the recipient's mail server, or at worst gets flagged as suspicious.
The full list of what cyber insurance actually requires from a small business in 2026 is laid out in the InsurableIT cyber insurance requirements FAQ. Ask your IT: send me a one-page report showing SPF, DKIM, and DMARC are all green for every domain we send mail from. Most reporting tools can produce this in five minutes.
Compromise scenarios
10. What does an M365 breach actually look like?
Most M365 breaches do not look like a movie. There is no skull and crossbones on the screen.
The pattern usually goes like this. Day zero: an employee clicks a fake login page, types their password, and approves an MFA prompt because the attacker socially engineered them into it. The attacker is now signed in as that user.
Within an hour: they create a hidden inbox rule that forwards every email mentioning the word "invoice" or "payment" to a Gmail address the attacker controls. They sit and watch for two weeks. They learn who pays whom, the writing style, the formatting of real invoices.
Day fifteen: a real invoice comes in from a real vendor. The attacker intercepts it (the user never sees it because the rule moved it), waits for the vendor to expect a reply, and then sends a doctored PDF with the bank account number changed.
Day twenty: your customer pays the wrong account. Nobody notices for thirty days. The first symptom is usually a customer calling to ask why their payment was not credited.
That is the realistic shape of most M365 breaches in 2026. Not ransomware on every screen. Quiet email fraud that drains a few wires before anyone realizes. If you want the full pattern, see the M365 breach FAQ on BreachShield365 for what to do in the first 48 hours.
11. How would I know if my email got hacked?
The honest answer is that most users do not notice. Modern attackers are quiet on purpose; they want to harvest information and move money, not announce themselves.
Signs to watch for on your side:
- Replies coming in to messages you never sent.
- A customer mentioning a strange request you do not remember making.
- Missing emails in your inbox (an inbox rule may be silently moving them to a folder you never check, like RSS Feeds or Conversation History).
- New sign-in alerts from cities you have never visited.
- Your laptop suddenly asking you to re-authenticate at odd hours.
On the IT side, the audit logs in Microsoft 365 will show foreign IP sign-ins, new mailbox forwarding rules, and consent grants to apps you did not approve. A quick monthly review by IT catches a lot of this.
If anything feels off, do not investigate it from the same computer the attacker may already be on. Tell IT first, from a different device. The companion post on recovering from a compromised M365 tenant has a fuller checklist of red flags. Ask your IT: are you reviewing sign-in logs and inbox rules monthly, and what does the report look like?
12. What's an "OAuth app consent attack"?
OAuth is the technology behind every "Sign in with Microsoft" or "Allow this app to access your calendar" pop-up you have ever clicked. It is not bad on its own.
The attack is when a bad actor tricks one of your staff into approving a malicious app. The fake email looks like "Microsoft Excel Add-in is requesting access to your mailbox." The user clicks Accept. The app, which is not Microsoft, now has permission to read every email and download every file.
Here is the dangerous part: a normal password reset does not kick out an OAuth app. You can change the user's password, reset the MFA, lock the account. The malicious app keeps reading mail until somebody specifically revokes the consent grant. Most small businesses do not check for these, and a stolen-mailbox investigation that ignores OAuth grants leaves the back door wide open.
The defense has two parts. First, lock down user app consent in Entra ID admin settings so that only an admin can approve new third-party apps; staff can request, but they cannot grant. Second, audit the apps already approved in your tenant at least once a year and remove anything nobody recognizes.
Ask your IT: who is allowed to consent to third-party apps in our tenant, have we audited the apps already approved in the last twelve months, and is "admin consent required" turned on for new apps?
Compliance and insurance
13. What's CIS Benchmark and why does it matter for me?
CIS stands for the Center for Internet Security, an independent nonprofit. They publish a free document called the Microsoft 365 Foundations Benchmark, which lists every security setting a tenant should have, with the exact value each one should be set to.
Think of it as a recipe written by people who do not work for Microsoft. There are about 60 settings in the small-business version. Each one says, in plain technical language, what the setting is, why it matters, what the right value is, and what audit log to check to confirm it was applied.
The reason it matters for you, even though you are not the one configuring them, is that auditors, insurance carriers, and customers asking security questionnaires increasingly use CIS as the reference. If you want to see which settings carry the most weight, our CIS M365 Benchmark checklist for small business walks through the high-priority items in plain terms. "Are you CIS-aligned?" is becoming a standard question on a Request for Proposal. If your IT can hand you a one-page report saying yes, with a date, you sail through. If they cannot, the deal slows down or the carrier writes the policy with carve-outs.
Ask your IT: when was the last time someone scored our tenant against the CIS Microsoft 365 Benchmark, do we have the report on file, and what was our score? Most small-business tenants score around 35 to 50 on the first run; a healthy target is 85 or above.
14. What does my cyber insurance actually require?
Insurance applications used to be one page. They are now thirty.
The list shifted hard between 2022 and 2025. In 2026 the typical small-business cyber policy expects all of the following, and an honest "no" on any of them tightens the policy:
- MFA on every account, no exceptions for the owner or the admin.
- Legacy authentication blocked across the tenant.
- An incident response plan that names who calls whom (counsel, IR firm, carrier, customers) in the first 24 hours.
- Regular backups that are tested at least annually.
- Endpoint detection and response (EDR) on every workstation, not just legacy antivirus.
- SPF, DKIM, and DMARC on every email-sending domain.
- Security awareness training with a sign-off log.
If you cannot answer yes to all of those, the carrier may decline the renewal, raise the premium dramatically, or carve out the most common claim categories from your coverage. Worse, after a real incident, the carrier may deny the claim if the application said yes and the post-incident forensics show no.
The full breakdown of what carriers ask in 2026, and what each item actually means in plain terms, is in the InsurableIT cyber insurance requirements FAQ. Bring that list to your IT before your next renewal questionnaire arrives, not after.
15. What's the difference between a "managed service" and "consulting" in this space?
Two very different products go by similar names, and most owners pay for the wrong one at least once.
Consulting (or a baseline deployment) is a fixed-scope project: somebody comes in, fixes a defined list of settings, hands you a report, and leaves. You own the result. The cost is usually fixed and known up front. A typical M365 baseline deployment for a 25-person company runs four to ten thousand dollars and takes two to four weeks.
A managed service is a monthly subscription where someone is on call to manage the tenant, respond to incidents, add new users, and keep settings aligned over time. The cost scales by user count, usually thirty to a hundred dollars per user per month depending on what is included. The contract is ongoing.
The first looks cheaper on day one and gets the lights on. The second looks more expensive but covers the slow drift that breaks most small businesses six months after the project closes (a new admin disables the legacy auth block, a new app gets approved without review, an exception gets added and never removed). Neither is wrong; they solve different problems.
The honest comparison, including which approach fits a 25-person company versus a 200-person company, is in our managed M365 security versus DIY guide. Ask yourself: do we have someone in-house who will keep the configuration current after the project ends, or do we need that built into the contract?
Already finished a hardening pass and wondering whether anything has slipped? The M365 quarterly drift-check playbook covers the four day-one alerts and the 90-minute review that keeps a hardened tenant honest.
The bottom line
You don't have to become a security expert. You do have to know enough to ask "is that on?" and recognize whether the answer is "yes, here's the report" or "we'll get to that next quarter."
Most M365 breaches we see at small businesses come down to the same three or four gaps: MFA isn't on every account, legacy authentication wasn't blocked, the email anti-spoofing records are missing or set to "monitor only," and nobody is reviewing the sign-in logs or inbox rules. Each gap is fixable in days, not months. The hard part is having someone whose job it is to actually do the fixing and keep it fixed.
If reading through this list made you think "I have no idea which of these we have," that's normal and that's the point. A baseline assessment takes a couple of hours and produces a one-page report you can hand to your insurance carrier, your auditor, or your board. Start there.
Get a Plain-English Tenant Report
See which of these controls are actually enabled in your tenant, in plain language, with a one-page summary you can hand to your insurance carrier or board.
Run Your Tenant AssessmentNext: the M365 quarterly drift-check playbook — the four day-one alerts, PowerShell drift queries, and 90-minute review that keeps a hardened tenant from quietly slipping.