Why identity deserves the first review
Microsoft 365 security is not limited to filtering unwanted email. The central question is what each identity can access and what an attacker could do after taking control of it. Identities include employees, administrators, guests, service accounts, application registrations, and increasingly automated or agent-like accounts.
Microsoft’s 2026 security research describes identity as a pressure point because access is spread across users, applications, providers, and automated identities. That observation is current Microsoft research, not proof that every Central Florida business is experiencing the same attack pattern. The practical lesson is straightforward: review access, not just alerts.
Establish a review owner
Assign one business owner and one technical owner. The business owner knows who should have access; the technical owner can verify settings in Microsoft Entra and Microsoft 365. If an outside provider manages the tenant, the business should still retain decision authority and documentation.
Create a monthly review for high-risk items and a quarterly review for broader access. Require an immediate review after termination, role change, suspected compromise, acquisition, or the addition of a major application.
Five identity questions
First, which accounts have administrative privileges? Separate everyday work from administrative work, require MFA, and review emergency or break-glass accounts. Emergency accounts should be tightly controlled, monitored, and tested according to the organization’s recovery plan.
Second, which users have access to sensitive mailboxes, SharePoint sites, Teams, OneDrive locations, finance data, or client records? Remove access that is based only on historical convenience.
Third, which guests and external collaborators remain active? Confirm the business purpose, sponsor, expiration date, and data scope for each guest. External sharing should be deliberate rather than the default way to move files.
Fourth, which applications have consent to read or modify organizational data? Review application permissions and remove unused or excessive consent. An application can become a high-impact identity even when no human employee thinks of it as an account.
Fifth, are self-service password-reset and recovery methods trustworthy? Attackers may target recovery processes, not just passwords. Confirm that recovery information is current, protected, and not controlled by a former employee or an unmanaged personal device.
Controls that usually matter
- Require MFA for administrators and all users, prioritizing phishing-resistant methods where available.
- Block legacy authentication that cannot enforce modern controls.
- Use conditional-access policies appropriate to licensing and business risk.
- Apply least privilege and use just-in-time elevation where the organization can support it.
- Review sign-in logs, risky-user alerts, mailbox rules, forwarding changes, and unusual application consent.
- Protect privileged accounts with separate identities and stronger monitoring.
- Maintain tested emergency access for a tenant lockout or provider outage.
Exact feature names and licensing requirements can change. Confirm current capabilities in Microsoft’s official documentation and your tenant’s administration center rather than relying on an old checklist.
What to do when a sign-in looks wrong
Do not treat every unfamiliar location as proof of compromise. Mobile networks, VPNs, travel, and cloud services can make location data imperfect. Look for combinations: unfamiliar device, unusual time, impossible travel indicators, new inbox rules, consent changes, repeated MFA prompts, or access to files outside the user’s normal role.
If compromise is suspected, preserve relevant logs, disable or contain the account according to your response plan, revoke sessions and tokens where appropriate, reset credentials through a trusted process, and inspect mailbox rules, delegated access, applications, and recent file activity. Coordinate with counsel and affected vendors when regulated data may be involved.
A review record worth keeping
Record the review date, reviewer, systems examined, exceptions, decisions, and follow-up dates. Do not store passwords or tokens in the record. Useful evidence includes an MFA coverage report, privileged-role list, guest list, application-consent review, and documented termination workflow.
The objective is not to make every sign-in look familiar. It is to ensure that every meaningful access path has an owner, a business purpose, and a response plan.
Every article remains a human-reviewed draft. This article is educational and does not replace legal, regulatory, insurance, or technical advice.