I work for an MSP supporting a college that is dealing with recurring Microsoft 365 account compromises. The usual pattern is that a student clicks a link in a phishing email, submits their credentials to a third-party form or fake login page, and the attacker then uses the account to send phishing messages to other students. We also see cases with several failed sign-ins followed by a successful one, although Entra does not always classify the activity as risky because the login can appear legitimate.
We are strengthening Conditional Access and moving toward a Zero Trust approach. Organization-owned Windows devices are being enrolled in Intune so we can eventually require device compliance. Students also use personal phones, however, and the college does not want to fully enroll or manage those devices.
The options we are considering include Defender for Office 365 P2 and Safe Links, Intune Mobile Application Management and App Protection Policies for BYOD, requiring protected mobile apps through Conditional Access, stronger MFA, compliant-device policies for college-owned systems, and possibly an MDR or SOC service for after-hours response.
Our biggest concern is limiting the damage when a student submits credentials to a phishing site, especially overnight when the IT team is not monitoring alerts. For organizations with large BYOD populations, what combination of phishing-resistant authentication, email protection, MAM, outbound-mail controls, user training, and managed detection has worked best? How do you protect personal phones without requiring full Intune enrollment, and what automated controls have helped contain compromised accounts?
5 Answers
Email filtering, external-sender banners, Safe Links, and blocking commonly abused form or invitation services can reduce the number of successful phishes. User training and simulated campaigns can lower click rates too, but training should not be the primary control at this scale. Assume that some users will eventually submit credentials and build the technical boundaries around that reality.
If the college cannot staff monitoring overnight, an MDR or identity-threat detection provider can be worthwhile, but only if it has authority to take action. Ask whether the service can revoke sessions, disable or restrict accounts, remove malicious rules, withdraw OAuth grants, and contain outbound phishing instead of merely sending an alert. Otherwise, the organization is still accepting the same after-hours response gap.
For personal phones, MAM and App Protection Policies are a good middle ground. They can require approved Outlook and other Microsoft apps, protect college data with app-level controls, and allow selective wiping without fully managing the device. For organization-owned computers, require Intune compliance separately. Also monitor and automatically respond to inbox rules, forwarding, suspicious OAuth consent, and session activity; those often remain after a password reset.
Make a compromise self-limiting after hours. Put sensible outbound-mail thresholds on student accounts, such as temporarily restricting an account that sends an unusually high number of messages in a short period, and automatically quarantine or disable it for review. Alert on new forwarding rules and suspicious inbox rules as well. These controls will not prevent the initial theft, but they can stop one compromised student from becoming a campus-wide phishing source at 2 a.m.
Be careful with thresholds because legitimate bulk messages or reply-all mistakes can trigger them. Use different limits for students, faculty, and service accounts, and make the response automatic but easy for the help desk to reverse.
The first priority should be phishing-resistant authentication, such as passkeys or FIDO2 security keys. Traditional MFA can still be bypassed through adversary-in-the-middle attacks or stolen session tokens, while a properly configured passkey is tied to the legitimate site and cannot simply be entered into a fake page. Block legacy authentication and require strong authentication through Conditional Access, including for students. Safe Links and mailbox remediation are still useful, but they should be treated as additional layers rather than the main fix.
A password reset should also revoke refresh tokens and active sessions. Otherwise, a stolen token may continue working even after the password has changed.