A Microsoft 365 tenant becomes part of the business’s security boundary as soon as it holds mail, files, meetings, identities, and access to connected applications. Growth makes that boundary harder to see. New employees arrive, administrators accumulate roles, external partners receive links, devices change, and a control that once covered ten people may behave differently across several offices. A useful Microsoft 365 security baseline therefore defines a small set of owned, testable protections instead of relying on whichever defaults happened to be present when the tenant was created.
Identity is the starting point because one successful sign-in can reach Exchange Online, Teams, SharePoint, OneDrive, and SaaS applications connected to Microsoft Entra ID. Microsoft Security Defaults provides a baseline that registers users for multifactor authentication, protects privileged activity, and blocks legacy authentication. Organizations with Microsoft Entra ID P1 or P2 and more complex requirements usually need a deliberately designed Conditional Access program instead. Licensing, break-glass access, user experience, and the effect on service accounts must be understood before enforcement.
The baseline below is intended for a growing business that wants practical control without pretending every Microsoft 365 subscription contains the same features. It connects identity, administration, devices, messaging, collaboration, audit evidence, and response ownership. Each control should have a responsible person, a documented exception path, and a validation record. For broader technology planning, the ALLMSP [Software Support](https://www.allmsp.com/category/software-support/) library and [Cybersecurity](https://www.allmsp.com/category/cybersecurity/) guidance provide related operating context.
Key decisions at a glance
- Choose Security Defaults or a tested Conditional Access design according to the tenant’s licenses and complexity, do not run overlapping approaches without understanding the result.
- Maintain at least two cloud-only emergency-access accounts with resilient authentication, exclusions from lockout-prone policies, alerts on use, and scheduled validation.
- Treat administrators, ordinary users, devices, mail, Teams, SharePoint, OneDrive, and third-party applications as connected control planes rather than isolated products.
- Use Microsoft Secure Score as a prioritized improvement signal, not as proof that the tenant cannot be breached or as a reason to enable every recommendation blindly.
- Record control owners, licensing prerequisites, pilot evidence, exceptions, audit visibility, and recovery tests so the baseline remains usable after deployment.
Anchor the Baseline in Identity and Resilient Administration
Start with an authoritative account inventory that distinguishes employees, contractors, guests, shared resources, service identities, synchronized accounts, and administrators. Every human identity should have a business owner, expected lifecycle, required access, and appropriate authentication method. Remove stale accounts only through a documented process that considers mailbox, OneDrive, legal-hold, and application dependencies. The objective is not simply a smaller directory, it is a directory in which the organization can explain why each identity exists and how access will end.
For a small tenant without advanced identity licenses or complex access requirements, Security Defaults can provide broad baseline protection. It requires multifactor registration, challenges administrators, blocks legacy authentication, and applies other Microsoft-managed protections. A tenant that needs location, device, risk, authentication-strength, or application-specific decisions should evaluate Conditional Access and its licensing requirements. Test policies with a pilot and report-only evidence where supported, exclude necessary emergency accounts, and retire legacy protocols or applications through an owned exception plan rather than by surprise.
Create at least two emergency-access accounts that are cloud-only, use the tenant’s onmicrosoft.com domain, and do not depend on the same federation, synchronization, phone, or administrative workstation as normal operators. Microsoft’s guidance calls for resilient phishing-resistant authentication, monitoring of every use, and validation at least every 90 days. These accounts are not daily super-admin identities. Store credentials and hardware keys through controlled custody, document the activation procedure, and investigate every sign-in.
- Inventory members, guests, service identities, synchronized objects, privileged roles, authentication methods, and account owners.
- Select Security Defaults or a license-appropriate Conditional Access design, then record the rationale and rollout scope.
- Use separate named administrator accounts for privileged work and keep ordinary email and browsing away from those identities.
- Test two or more emergency-access accounts on a schedule and alert a monitored channel whenever either account is used.
Control Devices, Applications, and Sessions Without Blocking Real Work
Authentication is only one part of a session. Record which Windows, macOS, iOS, Android, shared, and personally owned devices are allowed to reach business data, who manages them, and what minimum state is required. If Microsoft Intune or Conditional Access device controls are licensed, define enrollment, compliance, encryption, supported operating systems, screen lock, and retirement rules before requiring a compliant device. Where those controls are not licensed, use supported application settings, strong authentication, documented device standards, and narrow sharing rather than claiming a management capability the tenant does not have.
Review enterprise applications and consent as carefully as user accounts. An OAuth grant can provide durable access to mail, files, calendars, or directory data even after a password change. Record application owner, publisher, permissions, business purpose, consent source, and last review. Restrict user consent according to business needs, establish an administrator approval route, and remove unused grants after confirming the impact. Treat multifunction printers, websites, backup tools, and scripts that send mail as governed dependencies, legacy authentication should not remain enabled merely because the device was never inventoried.
Pilot session and device controls with people who represent executives, mobile staff, remote users, shared workstations, contractors, and line-of-business applications. Capture both security results and the recovery experience. A policy is not ready because an administrator can sign in, it is ready when legitimate users can complete their work, blocked conditions are explainable, support can collect the right evidence, and a rollback decision has a named owner.
- Create a device-access matrix covering ownership, platform, management state, encryption, patch level, and business data allowed.
- Inventory enterprise applications, delegated and application permissions, consent owner, publisher confidence, and review date.
- Replace legacy mail and automation dependencies with supported modern authentication paths, or document a time-bounded exception.
- Pilot sign-in, recovery, mobile access, desktop applications, browser sessions, and support escalation before broad enforcement.
Protect Mail, Files, Teams, and External Collaboration as One Data Path
Business data moves between Exchange Online, Teams, SharePoint, OneDrive, endpoints, and external recipients, so the baseline must follow the workflow. Configure accepted domains, anti-spoofing and mail-authentication records, safe administrative practices, and reporting paths for suspicious messages. Review forwarding rules, shared-mailbox delegates, transport rules, connectors, and privileged access to mail. Advanced Defender capabilities vary by subscription, so identify the protections actually licensed and enabled instead of describing a premium control as universal.
For SharePoint and OneDrive, set organization-wide sharing no broader than the business requires, then apply narrower site rules where projects contain sensitive or regulated data. Prefer authenticated, specific-person links for external work that needs accountability, define link expiration where appropriate, and require a named owner for every partner workspace. In Teams, remember that standard channel files live in the parent SharePoint site while private and shared channels have separate channel sites and membership. Membership and sharing reviews must reflect that architecture.
Recovery requirements should cover more than accidental deletion. Document native retention and recycle-bin behavior, legal or compliance retention, mailbox and OneDrive ownership after departure, and any separate backup or recovery service the business has selected. Test a representative recovery from each important data class and record elapsed time, permissions, version fidelity, and business acceptance. A backup claim without a tested restoration path is not a completed control.
- Verify SPF, DKIM, and DMARC design, accepted domains, external forwarding, connectors, shared-mailbox delegates, and suspicious-message reporting.
- Set external sharing at the organization and site level, favor accountable links, and assign owners to every partner workspace.
- Include parent sites and private or shared channel sites when reviewing Teams membership, files, and external access.
- Document retention, legal holds, recycle behavior, backup scope, recovery ownership, and the evidence from restoration tests.
Use Secure Score, Audit Evidence, and Exercises to Sustain the Baseline
Microsoft Secure Score helps teams identify recommended actions across identities, applications, devices, and data, but it is a posture measurement rather than a guarantee against compromise. Review each recommendation for licensing, user impact, existing mitigation, and implementation effort. Record whether the action will be implemented, tested later, addressed by another control, or accepted as risk by an authorized owner. Tracking the decision is more valuable than chasing a percentage that the business cannot explain.
Confirm that audit search is available to the people responsible for investigations and that retention meets the organization’s needs. Microsoft Purview Audit capabilities and retention periods differ by subscription and configuration. Test searches for representative events such as administrator role changes, mailbox activity, file sharing, application consent, and emergency-account use. Export or preserve evidence according to policy, and avoid assuming that a portal view will retain every event for as long as the business requires.
Run the baseline as a quarterly service review with shorter checks for high-risk events. Reconcile accounts and administrators, inspect emergency-access tests, review application consent and external sharing, check device and mail exceptions, assess Secure Score decisions, and sample audit evidence. At least annually, conduct a tabletop exercise that begins with a plausible compromised identity and ends with containment, recovery, communication, and lessons assigned to owners. ALLMSP’s [Microsoft 365 resource center](https://www.allmsp.com/category/software-support/software-support-microsoft-365/) can support deeper vendor-specific planning, and businesses that need help can [contact ALLMSP](https://www.allmsp.com/contact-us/).
- Create a Secure Score decision log with recommendation, license prerequisite, owner, impact, status, and accepted alternative.
- Validate audit searches for identity, administrator, application, mailbox, file-sharing, and emergency-access events.
- Review the baseline quarterly and after material licensing, identity, domain, acquisition, or collaboration changes.
- Exercise a compromised-account scenario and convert every gap into an assigned action with a due date and validation method.
Vendor documentation and ALLMSP resources
- Microsoft: Security defaults in Microsoft Entra ID
- Microsoft: Manage emergency access accounts in Microsoft Entra ID
- Microsoft: Microsoft Secure Score
- Microsoft: Learn about Microsoft Purview Audit solutions
- Microsoft: Best practices for securing privileged access
- ALLMSP Software Support
- ALLMSP Microsoft 365
- ALLMSP Cybersecurity
- Contact ALLMSP
Frequently Asked Questions
What is a Microsoft 365 security baseline?
It is a documented minimum set of identity, administrator, device, application, mail, collaboration, audit, and recovery controls that applies across the tenant. A useful baseline identifies owners, licensing prerequisites, exceptions, test evidence, and a review cadence rather than presenting a one-time checklist.
Should a small business use Security Defaults or Conditional Access?
Security Defaults is a practical Microsoft-managed baseline for tenants that need broad protection without complex policy requirements. Conditional Access is more appropriate when licensed organizations need decisions based on user, risk, device, location, application, or authentication strength. Evaluate the tenant’s licenses and dependencies before changing approaches.
How many emergency-access accounts should a Microsoft 365 tenant have?
Microsoft recommends two or more cloud-only emergency-access accounts. They should use resilient authentication, avoid dependencies shared with normal administrators, be excluded from policies that could create lockout, generate alerts when used, and be tested at least every 90 days.
Do administrator accounts need to be separate from normal user accounts?
Separate named admin identities reduce exposure because privileged accounts do not need ordinary email, browsing, or daily productivity activity. Assign only required roles, use strong authentication, monitor privileged changes, and avoid shared administrator identities that erase accountability.
Does Microsoft Secure Score prove the tenant is secure?
No. Secure Score measures posture against Microsoft recommendations and helps prioritize improvements, but a high score does not guarantee that a breach cannot occur. Consider licensing, user impact, compensating controls, and business risk for every recommendation.
What should be reviewed for Microsoft 365 enterprise applications?
Review the publisher, business owner, sign-in activity, delegated and application permissions, consent source, data reached, credentials or certificates, and last validation date. Remove unused grants only after confirming that no business workflow depends on them.
How should external sharing be secured in Teams and SharePoint?
Set the tenant maximum according to business need, apply narrower site settings for sensitive work, prefer authenticated specific-person links, require workspace owners, and review guests and links on a schedule. Include the separate sites created for private and shared Teams channels.
Is Microsoft 365 retention the same as backup?
No. Retention, recycle bins, legal holds, version history, and an independent backup solve different problems. Define the recovery scenarios the business cares about, confirm what each licensed service preserves, and test restoration with representative mail, files, and permissions.
How often should the Microsoft 365 security baseline be reviewed?
Review high-risk alerts and changes continuously, perform a structured tenant review at least quarterly, and reassess after mergers, domain changes, license changes, major application deployments, or new collaboration patterns. Test emergency access at least every 90 days.
What evidence shows that a Microsoft 365 control works?
Useful evidence includes configuration exports, pilot results, audit searches, sign-in and device outcomes, alert delivery, restoration tests, exception records, owner approval, and timestamps. Screenshots alone are insufficient if nobody can reproduce the test or explain the expected result.
