Five SaaS Tenant Misconfigurations We Found Last Week (And How They Compound)

We finished a sweep of 412 customer SaaS tenants last week — a mix of Microsoft 365, Google Workspace, and Salesforce environments belonging to companies between 50 and 1,200 employees. The original goal was a quarterly posture report. The interesting finding wasn't any single control. It was how five specific misconfigurations, each individually defensible to a CIO, compound into a near-trivial account takeover when they appear together.

67 tenants — 16% of the sample — had all five at once. Another 142 had three or more. None of the 412 customers were running an unsupported product, ignoring vendor recommendations, or operating without an IT team. Every one of these settings is something a competent administrator chose deliberately, often for a reason that sounded operationally sensible at the time. The compounding is what makes the chain dangerous, and the compounding is what flat checklists miss.

What happened

The five misconfigurations, ranked by frequency in our sample:

1. Admins exempt from MFA "for support reasons." Found in 73% of tenants. The pattern is consistent across vendors: a break-glass account or a support-tier admin is exempted from multi-factor enforcement so that on-call engineers can authenticate without a phone token at 2am. The exemption was created legitimately, and then it was never removed when the on-call rotation changed.
2. Personal email allowed for admin accounts. Found in 58% of tenants. Salesforce in particular still ships with no enforcement on admin email domains, so you'll find admins whose recovery address is a personal Gmail. M365 and Workspace both allow it through optional configuration that few customers tighten.
3. Session timeout greater than 8 hours. Found in 51% of tenants. The default in M365 is 90 days for "stay signed in" sessions. Google Workspace defaults to 14 days. Salesforce defaults vary by license tier. None of these defaults are wrong — they are tuned for end-user convenience — and most customers never narrow them for privileged accounts.
4. Ungated OAuth app installation. Found in 49% of tenants. We covered this at length in our admin-consent phishing post. The short version: any user can grant a tenant-scope OAuth token to a third-party app, and most administrators never enabled the consent workflow that would route those grants through approval.
5. No anomaly alerts on consent grants. Found in 44% of tenants. Even when consent governance is enabled, the alerts are usually not wired to anything. Microsoft's Entra audit log records every grant; Google's Reports API records every token issuance. In the tenants we reviewed, nobody was reading those signals on a schedule shorter than "during the next compliance audit."

Why it kept working

Each misconfiguration is individually defensible, which is exactly why they accumulate.

Exempting an admin from MFA "for support reasons" is a legitimate operational call when a single person carries the on-call pager and can't always reach a hardware token. Allowing personal email on admin accounts feels harmless when you trust the admin and the recovery flow has its own multi-factor step. An 8-hour session timeout is shorter than the 90-day default, so the admin who set it can credibly say they tightened the control. Ungated OAuth is the vendor default. Missing alerts on consent grants are the vendor default.

The compounding emerges only when you treat the five settings as a graph instead of a list. Picture an attacker phishing the admin's personal Gmail (item 2) to obtain a session-recovery email. That session, once established, doesn't require MFA (item 1) because the admin is exempt. The session lasts long enough for the attacker to pivot at human pace (item 3). During the session window, the attacker installs a malicious OAuth app with tenant-wide scope (item 4). And nobody is alerted on the grant (item 5). The chain goes from initial phish to refresh token in under fifteen minutes, and the only credential that ever changes hands is a personal-email password.

Remove any one of the five and the chain breaks. MFA on the admin account stops the personal-email pivot. Forced corporate email removes the personal-Gmail target. A 1-hour session timeout forces the attacker to phish twice. OAuth gating routes the malicious grant through a human reviewer. Real-time consent alerts flag the grant before the refresh token is used. That's the dependency-graph property: the attacker needs every node on their path to be unbroken, and the defender needs to break exactly one.

The reason flat checklists fail here is that they treat all 80 controls as having equal weight. They don't. Five of them sit on the critical path of a real, named, repeatable attack, and the other 75 raise the bar against attacks that are statistically rarer or more expensive. If you triage by graph instead of by control count, you spend your remediation budget on the five that actually move the needle.

What to check today

Three of these checks take under five minutes. The other two require a configuration change but no new tooling.

1. Pull a list of every account exempt from MFA. In Microsoft 365: Entra admin center → Conditional Access → Users excluded from policy. Cross-reference against the on-call rotation roster. Anyone on the exemption list who is not on the rotation today should be removed today. In Google Workspace: Admin console → Security → 2-step verification → Exceptions. Salesforce: Setup → Identity Verification → Excluded users. The break-glass account stays exempt; everything else moves under enforcement.
2. Audit recovery email domains for admin accounts. Any admin whose recovery email is on a free provider (Gmail, Outlook.com, Yahoo, ProtonMail) is a chain-step-2 risk. Force corporate-domain recovery emails for all privileged roles. In Salesforce, this requires a custom permission set; in M365 and Workspace it's a tenant setting.
3. Set privileged-account session timeout to 1 hour. M365: Conditional Access → Sign-in frequency → 1 hour for admin role assignments. Google Workspace: Admin console → Security → Google session control → 1 hour for super-admin and delegated admin roles. Salesforce: Profiles → Session Settings → Session timeout. Yes, your admins will sign in more often. That is the point.
4. Turn on the admin consent workflow. Same instruction as in our consent-phishing post: disable user-level consent and route every OAuth grant request through a named IT approver. Five minutes in the admin console; immediate effect on the attack surface.
5. Wire consent-grant alerts to a channel a human reads. M365: Microsoft Defender for Cloud Apps → Policy templates → Anomalous OAuth app activity. Google Workspace: Reports API → Token audit log → schedule a weekly review. The alert latency goal is hours, not weeks. If your SIEM integration is the only consumer and nobody is paged, this control does not exist for the purposes of the attack chain.

One more practical note. Customers above 500 employees consistently asked us to prioritize controls 4 and 5 (OAuth gating and consent alerts) over controls 1 and 2 (MFA and email). The reasoning was that admin-account hardening felt like an HR conversation while consent-flow gating felt like a configuration push. In our compounding analysis, that's the wrong order: items 1 and 2 are higher up the dependency graph. Fix the upstream nodes first.

How CELVEX Group tests for this

Our SaaS tenant assessment runs a single synthesized check rather than 80 individual controls in a flat list. Test SAAS-MULTI-MISCONFIG-CHAIN-001, defined in core/test_catalog/_supplement_saas_2026-03.py, scores the tenant on the five-node dependency graph and reports the shortest chain to admin takeover that the current configuration permits. The output is a graph, not a checklist: which nodes are present, which are missing, and which single remediation breaks the most chains.

The test is platform-aware. M365 tenants are scored against Conditional Access, Defender for Cloud Apps, and Entra audit logs. Google Workspace tenants are scored against the Reports API, App access control, and session-control settings. Salesforce tenants are scored against profile session settings, identity-verification exclusions, and connected-app policies. The output normalizes to a single chain-distance metric so a CIO running all three platforms can compare posture across tenants without translating between vendor vocabularies.

Customer-tier remediation patterns also fall out of the data. Series A and B companies tend to leave items 4 and 5 wide open because OAuth governance feels like an enterprise concern. Series C and later companies tend to fix items 4 and 5 first (often after a security audit) but leave items 1 and 2 in place because the admin team is small enough that exemptions feel necessary. Public companies have items 1, 2, and 3 mostly under control but routinely miss item 5 because alert hygiene is downstream of compliance hygiene. None of these patterns are vendor-specific; they're maturity-specific. The chain test makes the maturity gap visible in one report.

Bottom line

If you take only one thing from this post, take the chain. Five settings, present together, give an attacker a one-email path to admin. Three of the five take under five minutes each to fix. The reason customers don't fix them is that flat checklists hide which five matter; the reason CIOs don't push harder is that the operational pain of any single control feels disproportionate when you can't see the chain it sits on.

Pull the chain map. Show the dependency graph to whoever signs off on operational exemptions. Watch how fast the conversation about "admins exempt from MFA for support reasons" changes when the next sentence is "and that exemption is currently node 1 of a five-step path to tenant takeover that we have already mapped."