A Microsoft 365 security reset is a structured check of the controls that determine what an attacker could access after stealing a password or compromising an account. It gives your IT provider a practical baseline without assuming that every business needs the same licences, policies or security products.
This checklist is written for Australian SMEs using Microsoft 365 for email, files and collaboration. It focuses on the controls that make the greatest difference to account compromise, business email compromise and data exposure.
Do not switch on unfamiliar controls directly in production. Ask your IT provider to document dependencies, test changes with a small group and keep a safe recovery path before enforcing new access policies.
Before you change anything
Start by recording your current position. A reset should reduce risk without locking staff out of critical systems or breaking devices that still rely on older authentication methods.
Confirm these details with your IT provider:
- Which Microsoft 365 licences are assigned to users and administrators
- Whether Security Defaults or Conditional Access currently controls sign-ins
- Which accounts hold Global Administrator or other privileged roles
- Whether printers, scanners or applications use SMTP, POP or IMAP
- Which external applications have access to Microsoft 365 data
- Where audit logs and security alerts are reviewed
Agree who can approve policy changes and how you will reverse a change if it disrupts the business.
1. Protect administrator accounts
Administrator accounts can change security settings, create users, access data and weaken other controls. They should not be used for routine email, web browsing or day-to-day work.
Why it matters
A phishing email sent to an administrator's everyday mailbox can become a tenant-wide compromise if the same account also holds powerful roles. Separating normal work from administration reduces the damage a single stolen session can cause.
What to verify
- Every administrator has a separate account for privileged work
- Privileged accounts use strong multi-factor authentication (MFA)
- Administrator roles are assigned only where they are genuinely required
- Temporary access is removed when a project or support task finishes
- Emergency access accounts exist, are protected and generate an alert whenever used
Microsoft recommends maintaining cloud-only emergency access accounts so administrators can recover access if normal authentication fails. Follow Microsoft's current Security Defaults and emergency-access guidance rather than copying a generic policy from another tenant.
Owner: Your Microsoft 365 administrator, with management approving who should retain privileged access.
2. Strengthen sign-in controls
MFA is the starting point, not the complete sign-in strategy. The way MFA is enforced matters, as do the exceptions, older protocols and recovery methods around it.
Why it matters
Passwords are reused, phished and stolen. Modern sign-in controls add another decision before access is granted and can block authentication methods that do not support MFA at all.
What to verify
- MFA applies to every user, including administrators and contractors
- Security Defaults or Conditional Access provides tenant-wide enforcement
- Legacy authentication is blocked after dependent systems are identified
- Device-code authentication is restricted where the business does not need it
- Sign-in policies exclude only documented emergency accounts
- Policy changes are tested in report-only mode or with a pilot group before enforcement
Businesses without Conditional Access licensing can use Security Defaults as a baseline. Businesses with Microsoft Entra ID P1 or P2 can use Conditional Access for more targeted policies. Do not run both approaches as if they were separate layers. Choose the model that matches your licences and operational needs.
Owner: Your IT provider should design and test the policy. Management should approve any exception that weakens the baseline.
3. Review users, guests and privileged roles
Accounts accumulate over time. Former employees, old contractors, shared accounts and guest users often retain access long after the original business need has ended.
Why it matters
An inactive account can still be compromised. An unnecessary administrator role gives an attacker more control. A guest account can expose files and Teams conversations without appearing in the normal employee list.
What to verify
- Departed employees are blocked and their sessions revoked promptly
- Dormant accounts have a documented owner and purpose
- Guest access is reviewed regularly and expires where practical
- Shared accounts are replaced with named accounts wherever possible
- Global Administrator and other privileged roles are kept to a minimum
- Service accounts cannot sign in interactively unless the application requires it
Match this review against payroll, contractor and supplier records. Microsoft 365 alone cannot tell you whether every account still has a legitimate business purpose.
Owner: Human resources or management confirms who should have access. Your IT provider implements the changes.
4. Review third-party applications and consent
Microsoft 365 connects to document tools, accounting platforms, backup services, marketing applications and browser extensions. These integrations can retain access even after the person who installed them leaves.
Why it matters
Some applications can read mailboxes, access files or act as a user without needing that user's password again. A compromised or unnecessary application can therefore bypass controls that focus only on interactive sign-ins.
What to verify
- Every enterprise application has a current business owner
- Permissions match what the application actually needs
- Unused applications and stale credentials are removed
- Users cannot approve high-risk permissions without administrator review
- Application secrets and certificates have owners and expiry dates
- Supplier access is removed when the commercial relationship ends
Ask the application owner what would stop working before removing access. Remove unknown or excessive permissions only after the business impact is understood.
Owner: The relevant business owner confirms the application is required. Your Microsoft 365 administrator reviews and limits its permissions.
5. Secure email and reduce impersonation risk
Microsoft 365 email is a common target because attackers can monitor invoices, impersonate executives and insert themselves into payment conversations.
Why it matters
An attacker does not need to deploy ransomware to cause a serious loss. Access to one mailbox can be enough to redirect a supplier payment or collect sensitive client information.
What to verify
- SPF identifies the systems authorised to send mail for your domain
- DKIM signs outgoing messages for supported domains
- DMARC is deployed carefully and reviewed before moving to enforcement
- Automatic forwarding to external addresses is restricted
- Suspicious inbox rules and forwarding addresses are monitored
- Anti-phishing policies protect executives, finance staff and frequently impersonated domains
- Safe Links and Safe Attachments are configured where your licences include them
Email authentication should cover every legitimate sending service, not only Microsoft 365. Marketing, payroll, invoicing and support platforms may also send mail using your domain.
Owner: Your IT provider manages Microsoft 365 controls. Whoever manages DNS and external email platforms must be involved in SPF, DKIM and DMARC changes.
6. Control SharePoint, OneDrive and Teams sharing
External sharing is useful, but broad defaults can turn a single compromised account into access to years of client files and internal conversations.
Why it matters
The security question is not only whether an attacker can sign in. It is what that account can reach, download and share after the sign-in succeeds.
What to verify
- Anonymous links are disabled or limited to approved use cases
- External sharing defaults match the sensitivity of the information stored
- Guest access to Teams and SharePoint sites is reviewed regularly
- Sensitive sites have named owners and tighter sharing controls
- Old public links are removed when collaboration finishes
- Users understand the difference between internal, guest and anonymous sharing
Do not apply one restrictive setting to every site without checking how staff work with clients and suppliers. Start with high-risk sites, then establish a sensible tenant-wide baseline.
Owner: Business owners identify sensitive information and legitimate collaboration needs. Your IT provider configures and monitors the controls.
7. Confirm logging, alerts and investigation access
Security controls reduce the chance of compromise. Logs and alerts determine whether you can recognise suspicious activity and understand what happened afterwards.
Why it matters
Without usable logs, an incident response team cannot reliably determine which accounts, messages, applications or files were accessed. Logs that nobody reviews provide little practical protection.
What to verify
- Microsoft Purview audit logging is available for the licences in use
- Sign-in and audit-log retention meets your investigation and insurance needs
- Alerts exist for emergency administrator use and significant role changes
- Someone is responsible for reviewing security alerts
- Contact and escalation details are current
- Your incident response process explains how logs will be preserved
Test the escalation path with a harmless event. An alert is not useful if it goes to an unmonitored mailbox or a former employee.
Owner: Management assigns accountability. Your IT provider configures the alerts and confirms how evidence will be retained.
8. Plan for recovery before you need it
Microsoft provides resilient infrastructure, but resilience is not the same as recovering from deletion, malicious changes or a compromised administrator.
Why it matters
Retention settings, recycle bins and backups solve different problems. Recovery plans fail when nobody has tested how long restoration takes or who can authorise it during an incident.
What to verify
- Retention settings match legal, contractual and operational requirements
- Critical Exchange, SharePoint, OneDrive and Teams data has an agreed recovery method
- Any independent backup is monitored and tested
- Recovery administrators use separate, protected accounts
- The business knows its acceptable recovery time and data-loss window
- A restoration test has been completed and documented
The right approach depends on your data, licences, regulatory obligations and tolerance for interruption. Do not buy a backup product before defining what must be recoverable and how quickly.
Owner: Management defines recovery expectations. Your IT provider or backup provider demonstrates that the recovery process meets them.
Two Microsoft 365 changes to check in 2026
Microsoft changes cloud controls regularly. Two changes deserve specific attention during a 2026 reset.
Approved client application policies
Microsoft moved the Conditional Access "Require approved client app" control to a read-only state on 30 June 2026. Existing policies can continue to be enforced, but administrators can no longer create or edit policies that rely on that control. Review affected policies and plan the move to application protection policies using Microsoft's migration guidance.
SharePoint Content Security Policy
SharePoint Online Content Security Policy affects how custom SharePoint Framework components and external scripts load. Businesses using customised intranets or third-party web parts should confirm whether their solutions rely on untrusted or inline scripts and follow Microsoft's SharePoint CSP guidance.
These changes will not affect every SME. They belong in the review because they can create disruption or hidden gaps in tenants with older customisations and access policies.
Your 30-day Microsoft 365 reset plan
Use the checklist in a controlled sequence rather than trying to change every setting at once.
| Timeframe | Priority | Expected result |
|---|---|---|
| Today | Confirm privileged accounts, MFA coverage and emergency access | You know who can control the tenant and how access can be recovered |
| This week | Inventory users, guests, applications, legacy authentication and external sharing | Unnecessary access and unsafe dependencies are visible |
| Within 14 days | Test sign-in, email and sharing policy changes with a pilot group | High-value controls improve without avoidable disruption |
| Within 30 days | Close critical gaps, confirm alert ownership and test one recovery scenario | The baseline is documented and operationally tested |
Keep the completed checklist with the policy decisions, exceptions and named owners. Revisit it after major licence, supplier or staffing changes and at least once each year.
The practical next step
If you can answer every item confidently, give the list to your IT provider and ask them to document the evidence. If several answers are uncertain, begin with the free Microsoft 365 health check.
A checklist can identify obvious gaps. It cannot show how identities, applications, permissions and exposed data combine into a realistic attack path. The fixed-scope Microsoft 365 Security Review is designed to provide that independent answer and a prioritised remediation plan your IT provider can use.