CMMC Level 2 OAuth Review Checklist for Microsoft 365

When I assess Microsoft 365 for CMMC Level 2 OAuth risk, OAuth apps are one of the first places I look. A tenant can have strong MFA, good mail hygiene, and decent endpoint controls, yet still expose sensitive data through an app that was approved months ago and never reviewed again.

That matters because OAuth access often looks legitimate in logs. The app has consent, the token is valid, and the data access can blend into normal cloud activity. If you want a review process that holds up during an assessment, you need more than a screenshot of “allowed apps.”

Why OAuth app review belongs in CMMC Level 2 work

CMMC Level 2 does not name OAuth app review as a stand-alone control. Still, the practices behind Level 2 make the connection clear. If an app can access Exchange Online, SharePoint, OneDrive, or Teams data, it affects access control, least privilege, account management, auditability, and incident response.

I treat OAuth governance as part of normal control operation, not a side task. The DoD CMMC Level 2 assessment guide focuses on proving that access is authorized, limited, and reviewed. Microsoft also outlines how its government cloud services align to the program in Microsoft’s CMMC guidance. Neither source says, “approve every app and move on.” The point is ongoing control.

That distinction matters for evidence. During a readiness review, I don’t want to show only what apps exist. I want to show who approved them, what permissions they requested, what data they could reach, whether they still have a business purpose, and when I last checked them. A stale service principal with broad permissions can undermine months of hard work elsewhere.

Admin consent is not approval evidence. If I can’t show who reviewed the app, why it was needed, and what data it could reach, the control is weak.

For defense contractors and suppliers, the practical question is simple. Could a third-party app access Controlled Unclassified Information, or systems that store or process it? If the answer is yes, the app belongs in your access review, your change records, and your security monitoring.

The Microsoft 365 OAuth risks I look for first

The first issue I usually find is over-privileged Microsoft Graph access. An app asks for what it wants, not what you intended. I’ve seen tools approved for calendar syncing that also requested Mail.Read, Files.Read.All, offline_access, or Group.ReadWrite.All. In worse cases, application permissions allow broad tenant-wide access without a signed-in user. That changes the risk profile fast.

The second issue is dormant integrations. A marketing tool, e-signature add-on, reporting connector, or scheduling platform gets approved during a project. Six months later, nobody remembers who owns it. The vendor contract ends, the user leaves, or the business process changes, but the service principal still exists. Meanwhile, the app may still hold refresh tokens or retain access paths that nobody is watching.

Unsanctioned admin consent is another common problem. A global admin approves a multitenant app to solve a short-term request, and the decision never enters change control. I also watch for risky consent patterns from privileged users, especially when the app has no verified publisher, vague privacy terms, or unusual redirect URIs. Microsoft’s identity platform integration checklist is useful here because it shows what a well-built integration should look like.

Service principals with broad access round out the list. In Microsoft Entra ID, the app registration is only part of the story. The enterprise application and its granted permissions tell me what the tenant has actually trusted. If I see Directory.Read.All, Files.ReadWrite.All, or tenant-wide application permissions with no clear owner, I treat that as a review priority.

Small firms often miss this because OAuth sits between teams. Security thinks SaaS owners handle it. SaaS owners think Microsoft handles it. In practice, nobody owns it unless you assign ownership on purpose.

How I run an evidence-ready review in Entra ID

I start in Microsoft Entra ID with two inventories, App registrations and Enterprise applications. Then I line those up with audit logs, sign-in data, admin consent events, and ticket history. If the environment includes Defender for Cloud Apps, I use it to spot unusual app behavior and unsanctioned cloud use, but I don’t rely on one dashboard alone.

This is the minimum evidence set I want to keep current:

Review area	What I verify	Evidence I retain
App identity	Publisher, tenant type, owner, support contact	Inventory export, owner record
Permissions	Delegated and application permissions, admin consent status	Permission snapshot, approval note
Business need	Use case, data touched, system dependency	Ticket, change record, data classification note
Activity	Last sign-in, last token use, current necessity	Log extract, review date
Risk treatment	Approved, reduced, blocked, or removed	Decision record, revocation proof

That table looks simple because it should be simple. If your review process needs ten systems and three meetings, it won’t last.

Next, I compare requested permissions to the app’s real purpose. A ticketing add-on that reads one shared mailbox should not need SharePoint write access or directory-wide read permissions. I also check the authentication model. Microsoft publishes solid app registration security guidance, and I use it as a baseline for redirect URIs, verified domains, credential handling, and limiting sensitive properties.

Token hygiene matters too. If an app uses OAuth badly, the risk does not stop at consent. Short-lived access tokens, careful refresh token handling, and narrow scopes reduce blast radius. For a concise mapping of token practices to NIST 800-171 and Level 2 expectations, I often reference this OAuth token security write-up.

I document the decision at the same time I make it. That includes who reviewed the app, what changed, and when the next review is due. Otherwise, the record disappears, and the next audit becomes an archaeological dig.

A practical checklist I use for ongoing OAuth review

In my Small Business IT work, OAuth review is tied to Cloud Infrastructure, Cloud Management, and every Office 365 Migration. It also supports Cybersecurity Services, Endpoint Security, Device Hardening, and a Secure Cloud Architecture. For teams that want Managed IT for Small Business, Technology Consulting, and Tailored Technology Services, this is part of daily governance.

The same discipline strengthens Infrastructure Optimization and Business Continuity & Security. I also see it matter during Digital Transformation projects, Data Center Technology upgrades, and broader IT Strategy for SMBs. Even in Restaurant POS Support and Kitchen Technology Solutions, shared mailboxes, booking tools, and reporting apps often connect back to Microsoft 365. A dependable Business Technology Partner builds this into Innovative IT Solutions because access review is part of doing business safely.

Here is the short checklist I use operationally:

• Export all enterprise applications and service principals with granted permissions.
• Flag any app with tenant-wide application permissions or high-risk Graph scopes.
• Verify a named business owner for every app, not only a technical contact.
• Confirm the approval path, including whether admin consent followed change control.
• Review last activity and remove dormant third-party integrations on a set schedule.
• Require stronger scrutiny for multitenant apps, unverified publishers, and broad offline access.
• Record the decision, reviewer, date, and supporting logs in a place you can retrieve fast.
• Re-check the list after mergers, vendor changes, role changes, and major Microsoft 365 updates.

If a review ends with “we think it’s okay,” I treat it as incomplete. I want a named owner, a business reason, a permission decision, and preserved evidence. That standard works for small firms because it is strict enough to matter and simple enough to repeat.

Conclusion

The hidden risk in Microsoft 365 often isn’t a broken password policy. It’s an approved app that still has access no one remembers granting. That is why I treat CMMC Level 2 OAuth review as access governance, not app housekeeping.

A strong process is plain and repeatable. Inventory the apps, test the permissions against business need, remove what no longer belongs, and keep evidence as you go.

When that habit is in place, your tenant is easier to defend, easier to explain, and easier to assess.