The operator gap: why your Microsoft 365 already detects the risk but never fixes it

The tool that diagnoses is not the tool that cures

Microsoft put an extraordinary instrument panel into the hands of every Microsoft 365 administrator. Secure Score grades identity posture and puts a number on security debt. Microsoft Defender correlates signals across Exchange, Endpoint, Identity, and cloud apps. Entra ID surfaces Conditional Access, risk reports, and sign-in logs. Purview classifies sensitive data and tracks its movement. This is, without exaggeration, front-line instrumentation — the kind of telemetry that a decade ago only the largest enterprises' security teams ever saw.

And yet the risk does not fall. The panel flags the problem in red for months. The administrator sees it every time they log in. The finding migrates from one quarterly report to the next without moving an inch.

The reason is not negligence. It is a category confusion the whole industry carries: we treat detection as if it were remediation. It is not. Detecting a risk and closing it are two different jobs, with two different costs, and the second is almost never included in the first. That distance between "the system saw it" and "someone fixed it" is what we call the operator gap.

This article explains why the gap exists, where it shows up most dangerously in an average Microsoft 365 tenant, and why the answer is not another audit but a change of category.

Why detection without remediation is the natural state — not the accident

It helps to take the blame off the administrator, because the problem is structural, not personal.

Microsoft's detection tools are designed to inform, not to act unsupervised. And for good reason: a tool that reconfigures your tenant on its own — turning off protocols, forcing policies, revoking permissions — is a tool capable of cutting off your mail, locking your CEO out mid-trip, or breaking a billing integration on a Tuesday at 3 p.m. Microsoft, correctly, leaves the decision to execute in human hands. Secure Score recommends. Conditional Access must be configured. Defender alerts must be triaged and closed. The operative verb always lands on a person.

The problem is that this person — the IT administrator at a mid-sized company in Mexico, Colombia, Chile, or the United States — has neither the time nor, often, the specialist depth to execute every recommendation with confidence that it will not break something in production. Every Secure Score fix is a micro-decision about risk: _what falls over if I force this? who calls in angry?_ Multiply that by dozens of findings and you have the real reason the panel stays red. It is not that nobody knows what to do. It is that doing it well, with a safety net, costs specialist hours that daily operations never free up.

That is why the industry's dominant model — the audit as a deliverable — solves the wrong problem. A consultant connects, scans, and ships a PDF with forty prioritised findings. The document is correct. It is also inert. The audit transfers the system's information to the customer but leaves the work — the one piece that actually moves the risk needle — exactly where it was: pending. Six months later the next audit reports the same forty findings, and the customer pays again to be told what they already knew.

The audit-as-a-PDF is not bad. It is incomplete by design. It detects. It does not operate.

The five default settings that best illustrate the gap

To stop this from being abstract: here are five configurations that show up, with uncomfortable frequency, switched on by default or left unhardened in Microsoft 365 tenants that otherwise "have MFA." Each is detectable with the tools the customer already pays for. Each persists because detecting it is not fixing it.

1. Legacy authentication that bypasses MFA entirely

The most dangerous failure, because it nullifies the very defence people rely on most. Legacy authentication — old protocols like POP3, IMAP, MAPI, or basic SMTP AUTH — does not understand modern factors. When a mail client connects via basic auth, it presents a username and password, and that is it: the MFA challenge never fires, because the protocol does not know how to ask for it. It does not matter how many factors a user has configured; if the legacy-auth back door is still open, an attacker with the password walks in without MFA ever intervening.

Microsoft knows this and acted: starting 1 October 2022 it disabled basic authentication for MAPI, RPC, Offline Address Book, Exchange Web Services, POP, IMAP, Exchange ActiveSync, and Remote PowerShell in Exchange Online. But it left a deliberate exception: basic SMTP AUTH, which was not turned off automatically in tenants where it was in use, so as not to break printers, scanners, and line-of-business apps that depend on it. Per the Exchange team's updated timeline, basic SMTP AUTH will only be disabled by default for existing tenants at the end of December 2026.

Operational translation: there are tenants — perhaps yours — with an authenticated send path that ignores MFA, switched on for compatibility, that will stay on until someone turns it off by hand or until 2026. Defender and Entra show legacy-auth sign-ins in the reports. Neither blocks them for you. That is the operator gap in its most literal form.

2. Admin MFA configured but not enforced

The second most common pattern is subtle: MFA is "enabled" on the tenant, but not enforced for the accounts that matter most. A Conditional Access policy stuck in report-only mode, an "emergency account" exclusion that was never revisited, a global administrator inherited from the migration who never went through the MFA registration flow. The result is an account with full tenant privilege protected by a password alone.

Accounts with privileged roles — Global Administrator, Privileged Role Administrator, Exchange Administrator — are the highest-value target in any tenant. The CIS Microsoft 365 Foundations Benchmark treats them as a separate category precisely for this reason. Secure Score flags the absence of enforced admin MFA as one of its highest-weighted findings. And still it persists, because enforcing it well — without locking out the legitimate emergency account, without breaking an automated service that uses a privileged identity — is a precision operation, not a switch.

3. DMARC published at p=none — visibility without protection

DMARC is the standard that tells receiving servers what to do with a message claiming to come from your domain that fails authentication. It has three policies: `p=none` (monitor only), `p=quarantine` (send to spam), and `p=reject` (refuse outright). The vast majority of domains that publish DMARC stop at `p=none` — and `p=none` blocks nothing. It is an observation mode: the receiver sends you reports of who is spoofing your domain, but delivers the spoofed mail anyway.

Stopping at `p=none` is the equivalent of installing a security camera that records the burglar walking in but never locks the door. The reason almost nobody advances to `p=reject` is not ignorance: the path from `p=none` to `p=reject` requires inventorying every legitimate mail source (the billing platform, the marketing platform, the ERP, the CRM), aligning SPF and DKIM for each, and advancing the policy in stages without knocking out legitimate mail along the way. It is sustained operator work, not a single DNS edit. And so it stays half-done for years.

4. Anonymous external sharing — the "Anyone with the link" links

SharePoint and OneDrive allow "Anyone with the link" links: URLs that grant access to a file or folder to whoever holds them, with no authentication and no record of who entered. They are convenient. They are also, frequently, a more permissive default than the organisation realises, and the cause of data exposures nobody consciously authorised.

An anonymous link to a folder with contracts, payroll, or tables of personal data — tax IDs, national IDs, customer numbers — is exactly the kind of exposure that LFPDPPP Art. 18 obligates an organisation to prevent, and that an attacker does not need to "hack": it is enough to find the link forwarded in an email, a chat, or an indexed document. Purview and SharePoint sharing reports detect these links. Restricting the sharing policy to "authenticated users only" or "people in the organisation only," and cleaning up the anonymous links already issued, is once again a deliberate operation the panel does not execute for you.

5. Ungoverned OAuth consent — the attack that does not need your password

The most modern and the least understood. In the illicit consent grant attack, an attacker registers an application in Entra ID that requests permission to read mail, files, or contacts, and tricks the user into consenting — not into surrendering their password. The user clicks "Accept" on a consent screen that looks legitimate, and the malicious application obtains a token with persistent access to their data. MFA does not intervene, because the user is not authenticating to the attacker: they are granting permission to an app.

Microsoft documents this vector in its consent-phishing protection guidance for Entra ID and in the Defender for Office 365 manual for detecting and remediating illicit consent grants. The defence is governance: restrict user consent to applications from verified publishers and low-risk permissions, require administrator approval for the rest, and periodically review which applications hold which permissions in the tenant. Entra surfaces every granted consent. Deciding which to revoke, configuring the approval flow, and keeping the review alive is, again, continuous operator work.

The common thread: none of the five is a knowledge problem

Look at the five together and the pattern jumps out. None persists because the administrator does not know it exists. All five are detectable — most with the tools the customer already pays for, and simiriki's 201 detection rules (155 via Microsoft Graph + 46 via Azure Resource Manager) cover them with a verdict and evidence. All five persist for the same reason: closing them is a precision operation that risks breaking production, and that work is never included in the diagnosis.

That is the whole thesis of the operator gap. The bottleneck of mid-market security is not visibility. It is execution. And a market that sells more and more visibility — more panels, more scores, more reports — is solving, with growing sophistication, the problem that was already solved.

The cost of leaving the gap open

There is no need to invent figures to size the risk. IBM's Cost of a Data Breach Report 2025 puts the global average cost of a data breach at USD 4.44 million (down from USD 4.88 million in 2024). That number is an average that includes large enterprises, so it is not the expected cost of an incident at a mid-sized company — but the direction is unambiguous, and the same report attributes the 2025 reduction precisely to faster detection and containment enabled by automation. In other words: the value is not in detecting better — the tools already do that — but in containing and closing faster. Which is exactly the operations work the gap leaves undone.

For a Mexican or Latin American company, the regulatory cost stacks on top of the incident cost: LFPDPPP obligates an organisation to "establish and maintain" security measures, and "maintain" is not satisfied by an annual PDF of findings. The obligation is operational and continuous, not documentary.

The category shift: from "audit-as-a-PDF" to "operate-it-for-you"

If detection is already a solved problem and execution is the bottleneck, the conclusion is direct: the product that matters is not another audit. It is the operation.

This is how simiriki structures the funnel, and why it is a change of category rather than a price variant:

The Audit is free. Connect your Microsoft 365 in read-only mode, we run the automated scan of the 155 Microsoft Graph rules of the 201-rule library, and you receive the full report — 0–100 posture score, prioritised findings, remediation plan, and a bilingual brief. No cost, no card. The diagnosis stops being the product, because the diagnosis is the part Microsoft's tools already know how to do. Charging to tell you what your own Secure Score already shows you is charging for the wrong work.

Current Operation status: General checkout is closed. Only an authorized pilot bound to the buyer and a completed Audit can initiate purchase through the outcomes API; all other customers start with the free Audit.

The sentence that sums it up fits on one line: your Microsoft tools already know what's wrong. They won't fix it. We do — the diagnosis is free, you pay only to remediate.

The takeaway, even if you buy nothing

If this page leaves you with a single defensible idea, let it be this: in Microsoft 365 security, detection and remediation are two distinct products, and the market has been selling you the one you already have solved. The next time you evaluate a "security audit," ask one question: _does this detect, or does this execute?_ If the answer is "we hand you a report," you are paying for more visibility into a problem whose bottleneck was never visibility. The work that moves the needle is the work that closes the finding — and that is the only one worth paying for.

Next step

Seeing your own operator gap takes less than it took to read this article. Connect your Microsoft 365 in read-only, no card, and receive your posture report — including these five failures, if they are present in your tenant — in minutes.

Run your Audit free →

---

Sources cited in this article:

• Microsoft Learn · Deprecation of Basic authentication in Exchange Online — basic auth disabled for MAPI/RPC/OAB/EWS/POP/IMAP/EAS/RPS from 1 October 2022; basic SMTP AUTH the exception, default-off for existing tenants by end of December 2026
• Microsoft Learn · Protect against consent phishing (Microsoft Entra ID)
• Microsoft Learn · Detect and remediate illicit consent grants (Microsoft Defender for Office 365)
• RFC 7489 · DMARC — `p=none` is monitor-only; only `p=quarantine`/`p=reject` instruct the receiver to act
• Microsoft Learn · Manage external sharing for SharePoint and OneDrive — "Anyone" links
• IBM · Cost of a Data Breach Report 2025 — global average USD 4.44M (USD 4.88M in 2024)
• CIS Microsoft 365 Foundations Benchmark v4.0.0 (November 2024)
• CISA · SCuBA M365 Secure Configuration Baselines
• NIST Cybersecurity Framework v2.0
• Chamber of Deputies · LFPDPPP Art. 18 — security measures

Full source index: simiriki.com/sources