Universities can permit OAuth IMAP even with block-legacy-auth policies
Connecting to a Microsoft 365 mailbox at a university or enterprise tenant where the org has disabled Basic Authentication and recommends Block-Legacy-Authentication Conditional Access policies.
The widespread assumption is that an org with Conditional Access set to Block Legacy Authentication will block IMAP regardless of which auth method the client uses — because in CA configuration UIs the protocols POP, IMAP, MAPI etc. are often grouped together under a single legacy bucket. Empirically that is not always true. A live test against a major university tenant (UIUC) with strict IT controls succeeded end to end: MSAL device code flow with Thunderbird's published public client ID (no Entra app registration, no admin consent), scope IMAP.AccessAsUser.All plus offline_access, then XOAUTH2 SASL into outlook.office365.com 993, then SELECT INBOX returning a real message count. Microsoft globally allow lists first party client IDs across tenants, and CA policies built from the standard templates discriminate by auth method not by protocol. So a tool that uses OAuth XOAUTH2 against IMAP can work against a tenant where a tool using basic auth IMAP would be rejected — the same protocol, the same port, different auth.
Before assuming a Conditional Access policy will block your third party IMAP client, run a local MSAL device code plus XOAUTH2 SELECT test from any random network. If the CA policy is discriminating on auth method (the common case) the test will succeed. If it discriminates on protocol or location the test will fail with a specific Microsoft error that tells you which knob to ask the admin about.