Key idea
Privileges are upstream of authentication
You can MFA a bad pattern into existence. If an app or automation retains broad privileges, identity hardening doesn’t matter.
Research Note · Identity & Access
Identity Design Failures
You can’t fix with MFA
MFA is powerful, but it is not architecture. Many identity compromises are not caused by weak authentication—they’re caused by flawed identity design. This note explores the structural mistakes that create systemic risk in Microsoft Entra ID and Google Workspace, and why “just turn on MFA” doesn’t solve them.
Entra & Workspace realities
Authority & delegation flaws
Architecture > Authentication
The problem isn’t a missing factor. The problem is that the wrong identities can do the wrong things in the wrong places.
Executive summary
Your breach risk is an identity design problem
When identity architecture is wrong, compensating controls—MFA, device trust, CASB, phishing gates—buy time, not safety. The key risk is who can act as whom, not how they sign in.
Misconception
MFA closes the door
Attackers don’t need to bypass MFA when automation, consented apps, or design flaws let them operate entirely inside your tenant.
Outcome
Fix patterns, not just factors
Meaningful improvement comes from reshaping roles, delegations, and ownership, not piling more auth challenges on human logins.
Architecture failures
Three identity design flaws MFA cannot fix
These patterns enable durable compromise even when every user is forced to MFA on every login.
Pattern #1
Automation identities with human authority
- Power Automate / Apps Script running with user-level access
- Workflows that delete mail, copy files, or sign tokens
- “Migration accounts” never revoked, never rotated
Automation should not impersonate humans. When it does, you’ve created a privileged service account disguised as a person.
Pattern #2
OAuth consent as privilege escalation
- A single button yields durable API access
- App grants are invisible to most SOC processes
- Phish → consent → infinite scope → MFA irrelevant
You don’t need to “hack auth” when the user gives you admin-level scopes.
Pattern #3
Shared mailboxes as unowned super-users
- Nobody checks sign-in events
- Multiple humans share access → no accountability
- API use looks “systemic” → ignored
Shared identities remove the possibility of blame. They also remove the possibility of detection.
Consequences
When design flaws meet real adversaries
Attackers don’t care about your authentication policy. They care about leverage. Identity is the shortest path to it.
Persistence without implants
OAuth tokens, mailbox rules, apps scripts—no need to reinfect endpoints.
Privilege without visibility
The riskiest entities never sign in: service accounts, shared mailboxes, integrations, and migration tooling.
Human blind spots
Your best analysts ignore signals that don’t look like malware or brute force. Identity compromise often looks like “normal business automation.”
Where to start
Fix the system, not the login
Recovery begins with design, not enforcement.
Separate automation from human identities
Require app/service accounts for all non-human processes. Assign least privilege scopes. Audit ownership quarterly.
Limit consent authority
Fewer people should be able to approve broad app scopes. Review all existing grants ≥ every 90 days.
Kill shared mailboxes
Replace them with delegated access and traceable ownership or use a monitored automation identity.
Retire Migration & “Legacy” accounts
If nobody can answer why an identity exists, it is an attacker beachhead.