New tools to block legacy authentication in your organization

Mike_Saulters So glad I'm not the only one drowning in all of this. Among my many, many other responsibilities, been attempting to implement this B-2-M transition for many years. For us, the suggestion to "simply use security defaults" is, to put it bluntly, irresponsible. So many changes, updates and many problems coming out of the woodwork has me breathing a sigh of relief that we didn't go that route.

Alex Weinert danielwood95 I've gone through our 3 tenants (don't ask, my response/answer will further angrivate me, LOL) and have all licensed humans assigned to one of 4 authentication policies:

Block Basic <-- Modern ONLY

Allow EAS OutlookService and SMTP <-- a few MacOS users with native Apple and 3rd party email clients

Allow EAS <-- many iPhone users with Apple Mail/EAS

Allow SMTP <-- LOB/IOT devices

The following "names" (get-user | ft Name, Auth*) remain without a particular policy (I.e., blank). Please shed light on what to do, if anything, with these IDs/objects. I've scoured the many available resources and can't locate anything specific about them...either no consideration has been made or it's in every resource I've reviewed (and am too blind to see it).

user_domain.tld#EXT# -- external user (mostly identities from our other tenants, but we have a few "true" external individuals)

"Shared" Mailbox without an Exchange License -- Public Folder replacement (we do not use Teams)

"Generic" Mailbox with an Exchange License -- shared department/service responsibilities (e.g., HR, Finance, etc.) and additional capabilities (e.g., flows, storage, management, etc.).

DiscoverySearchMailbox{...} -- I've learned (and forgotten) what this is for (far too many times to count).

Thank you, in advance, for direction/insight.