Why do Microsoft 365 misconfigurations create persistent risk even without malware?

Why This Matters for Security Teams

Microsoft 365 misconfigurations are dangerous because they preserve access paths after the original business reason has disappeared. Auto-forwarding, mailbox delegation, OAuth app consent, and disabled MFA can remain effective without malware, making the platform itself the persistence layer. That shifts the problem from endpoint detection to identity and configuration governance, where attackers can operate quietly inside legitimate workflow boundaries.

This is not an edge case. NHI Mgmt Group notes that 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, and that pattern generalises to collaboration platforms when controls are left in a permissive state. The same logic appears in Top 10 NHI Issues and in the control failures described by the NIST Cybersecurity Framework 2.0, where governance must track changes, not just incidents. In practice, many security teams discover the risk only after a mailbox, tenant rule, or delegated account has already been used for quiet exfiltration.

How It Works in Practice

The persistence comes from configuration state, not binaries. If an attacker can create an inbox rule that hides replies, enable auto-forwarding to an external address, or retain delegated access to a mailbox, they can keep collecting data even after a password reset or device cleanup. Malware is unnecessary because the platform is already trusted to route mail, honour delegated permissions, and execute user-level automation.

Security teams should treat these settings like standing access. The operational baseline is to inventory high-risk controls, review them continuously, and remove anything without a current business justification. That includes:

• Blocking or tightly limiting external auto-forwarding.
• Reviewing mailbox delegation, shared mailbox access, and Send As rights.
• Enforcing MFA on privileged and user accounts alike, including admin pathways.
• Monitoring OAuth app grants and consented permissions for persistent access.
• Logging and alerting on rule creation, permission changes, and suspicious transport rules.

For organisations that want a broader control lens, Ultimate Guide to NHIs is useful because it frames secrets, service accounts, and lifecycle governance as a single system. Microsoft also documents the control points through the Microsoft 365 security guidance, but the hard part is enforcement discipline: revoke what is no longer needed, and verify that a disabled control has actually been removed rather than merely hidden. These controls tend to break down in large tenants with many shared mailboxes, legacy inbox rules, and decentralised admin ownership because no single team can confidently attest to every persistent access path.

Common Variations and Edge Cases

Tighter configuration control often increases operational overhead, requiring organisations to balance user convenience against the need to prevent silent persistence. That tradeoff is especially visible in sales, support, and executive-assistant workflows, where mailbox delegation and forwarding are legitimate at one moment and risky the next.

Best practice is evolving, but current guidance suggests treating exceptions as time-bound and reviewable rather than permanent. A forwarding rule approved for a leave cover arrangement should expire automatically. A delegated mailbox used by a contractor should be removed when the engagement ends. In regulated environments, these reviews should be aligned to access certification and change management so that configuration drift cannot accumulate unnoticed.

Edge cases also matter. Shared mailboxes can appear benign while still exposing sensitive threads to multiple identities. Conditional Access gaps can leave a compromised session active even after a password reset. And if an attacker already has legitimate access, they may not need persistence in the classic malware sense at all, because the tenant itself provides continuity. The lesson from MongoBleed breach and Shai Hulud npm malware campaign is that exposed secrets and preserved access often outlast the initial intrusion, so remediation must remove the path, not just the payload.

Related resources from NHI Mgmt Group

• Why do non-human identities create compliance risk even when policies exist?
• Why do Microsoft 365 environments create persistent access risk?
• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?