What should a secure Microsoft 365 setup include for a small business?

Microsoft 365 can place email, files, identities, applications, sharing, devices and security controls within the same organisational environment. For a small business, this can simplify day-to-day work, but it also means that the Microsoft 365 tenant may become central to how the organisation operates.

A secure Microsoft 365 setup therefore involves more than creating mailboxes and turning on multi-factor authentication. Administrative access, ordinary user accounts, application permissions, email security, computers, backups, monitoring and recovery arrangements all need to be considered together.

Some of the controls in this guide come directly from published Microsoft or UK National Cyber Security Centre guidance. Others are implementation choices that Evening Computing commonly recommends when they are appropriate to the organisation. The distinction matters: a product or particular licence should not be presented as mandatory when the underlying security principle can be achieved in different ways.

This guide is designed around security principles that should remain useful even as Microsoft products, licences and interfaces change. Microsoft services, licensing, threats and recommended practices still need periodic review, but the underlying questions remain similar: who has access, from which devices, through which applications, what information is protected, how unusual activity is detected, and how control can be recovered if something goes wrong.

The appropriate implementation should therefore reflect the organisation’s size, systems, working practices, risk and budget rather than treating any particular Microsoft licence or product combination as a permanent checklist.

Use the links below to jump to the section most relevant to your question.

• Where these recommendations come from
• Use individual accounts and least privilege
• Separate everyday work from administration
• How many administrator accounts should there be?
• Configure emergency access accounts
• Require multi-factor authentication
• Use Security Defaults or Conditional Access deliberately
• Control older authentication and application access
• Protect email and the domain
• Where Defender for Office 365 Plan 2 fits
• Manage devices with Intune
• Connect device compliance to access
• Choose the appropriate level of endpoint protection
• Use an independent backup layer
• Verify auditing and monitoring
• Review access and sharing over time
• Choose licensing after defining the controls
• A practical layered model for a small business
• What these controls do not guarantee
• Further Guidance and Support

Security guidance is more useful when it is clear whether a control is recommended by a platform provider, by an independent security authority, or as part of a particular implementation approach.

Microsoft publishes guidance on areas such as administrative accounts, least privilege, emergency access, multi-factor authentication, Conditional Access, Microsoft Defender, Intune and application permissions.

The UK National Cyber Security Centre publishes wider guidance for organisations covering areas such as separate administrator accounts, two-step verification, device management, independent backups and email transport security.

Evening Computing uses these sources when planning Microsoft 365 environments, but the choice of a particular product or licence is a separate judgement.

For example, the NCSC recommends managed control of organisational devices. In a Microsoft 365 environment, Evening Computing often recommends Microsoft Intune as the platform used to provide that management. The underlying principle comes from wider security guidance; the choice of Intune is an implementation decision.

The same distinction applies to Microsoft Defender licences and third-party backup services.

Each person should normally have their own organisational account rather than several people sharing the same identity.

Individual accounts make it easier to control access when someone joins, changes role or leaves. They also make actions easier to attribute and allow security controls to be applied according to what each person actually needs.

Microsoft provides different administrative roles for different responsibilities. Someone who needs to manage users, Exchange Online, SharePoint or security settings does not automatically need Global Administrator rights.

Microsoft’s guidance is to apply least privilege and use the role that provides the access needed for the task.

Global Administrator remains necessary for particular operations and for emergency recovery, but it is one of the most powerful roles in the tenant. It should not be the default permission given to everyone who occasionally carries out an administrative task.

Using separate identities for everyday work and privileged administration is not an Evening Computing-specific recommendation.

Microsoft recommends that administrators use an ordinary non-administrator account for regular work such as email and Microsoft 365 applications and use a separate administrative account only when administrative access is required.

The NCSC also recommends separating normal user activity from administrator activity when using online services.

A typical arrangement for someone responsible for Microsoft 365 might therefore be:

• • [email protected] for email, OneDrive, Teams, Microsoft 365 applications and ordinary work
  • a separate administrator identity used only for administrative work

The administrative account should not normally be used for ordinary email, general internet browsing or other day-to-day activity.

This limits how often privileged credentials are exposed during normal work. A compromised ordinary account remains serious, but it should not automatically provide the attacker with the same administrative authority used to change tenant-wide settings.

Microsoft also states that a dedicated account used only to administer cloud services does not need a Microsoft 365 productivity licence simply because it performs administration. Premium Microsoft Entra, security or management capabilities applied to that identity can still have separate licensing requirements, so the complete licensing arrangement should be checked before deployment.

There is no useful rule that says a small business should have only one administrator identity simply because it has only a few members of staff.

The number of named administrative identities should reflect who actually needs to administer the tenant. Each person carrying out administration should normally have their own identifiable administrative account rather than sharing an everyday administrator login.

In addition to these named administrative identities, Microsoft recommends maintaining at least two emergency access accounts with the Global Administrator role.

These emergency accounts are different from the accounts used for normal administration. They are designed for exceptional situations where normal administrative access is unavailable.

For example, a very small business where one person normally administers Microsoft 365 may reasonably have:

• • one ordinary licensed work account for that person
  • one separate named administrative account for routine administration
  • two separate cloud-only emergency access accounts reserved for recovery

This means the tenant can contain more privileged identities than there are people carrying out day-to-day administration.

That is intentional. The emergency accounts exist for resilience rather than convenience.

Where several people carry out administration, each should have their own appropriate administrative identity and role assignments. Routine use of shared administrator credentials should be avoided because it reduces accountability and makes access harder to revoke or investigate.

Microsoft recommends two or more emergency access accounts so that an organisation is less likely to lose administrative control of its tenant if normal sign-in methods or administrator accounts become unavailable.

Microsoft’s current guidance describes these accounts as cloud-only identities using the tenant’s .onmicrosoft.com domain. They should not depend on federation or another identity system that could itself be unavailable during an incident.

The emergency accounts are permanently assigned the Global Administrator role because their purpose is recovery when normal administrative methods cannot be used.

Microsoft currently recommends phishing-resistant authentication for these accounts, including FIDO2 passkeys or certificate-based authentication where an organisation already has the necessary infrastructure.

The authentication method should also avoid unnecessary dependencies on the same systems used by normal administrators.

Emergency access accounts should:

• • be used only for emergency access
  • remain separate from ordinary administrator accounts
  • use strong phishing-resistant authentication
  • be excluded from Conditional Access policies that could block or restrict access during an emergency
  • have their credentials or authenticators stored securely
  • generate attention when they are used
  • be tested periodically
  • remain accessible to the authorised people responsible for recovery

Microsoft currently recommends validating these accounts at least every 90 days and after significant changes.

The organisation should also consider which computer would be used during an emergency. An account intended to recover control of the tenant should not depend on an unknown or poorly protected device.

Passwords alone should not be the main protection around Microsoft 365 accounts.

The NCSC recommends two-step verification for organisational online accounts where it is available, and Microsoft provides several ways to require multi-factor authentication within Microsoft 365 and Microsoft Entra.

The authentication method also matters. Microsoft increasingly recommends moving away from authentication methods that can be phished or intercepted and towards phishing-resistant methods such as passkeys, Windows Hello for Business and FIDO2 security keys.

This is becoming particularly important because Microsoft has announced the retirement of its own SMS and voice-call delivery for Microsoft Entra authentication. From 1 September 2026, users who are enabled for SMS or voice authentication will begin to be automatically enabled for passkeys and prompted to register one. From 1 February 2027, Microsoft-provided SMS and voice-call authentication will be retired in Microsoft Entra ID.

This does not mean that SMS and voice authentication will become technically impossible after that date. Organisations with a genuine operational, regulatory or technical requirement to retain these methods will be able to use a customer-managed telecommunications provider. However, Microsoft’s recommended direction is to move users to phishing-resistant authentication rather than continue relying on telephone-based MFA.

For privileged Microsoft Entra roles, Microsoft currently recommends phishing-resistant MFA. Supported methods can include passkeys stored on suitable FIDO2 security keys and other supported phishing-resistant authentication methods.

Phishing-resistant authentication should not be interpreted as making the complete account impossible to compromise. Security still depends on areas such as device protection, session tokens, account recovery and whether weaker authentication methods remain available as alternative ways to sign in.

Microsoft continues to classify FIDO2 passkeys as phishing-resistant because the credential is bound cryptographically to the legitimate service rather than being a code that can be copied into a phishing site. The wider account and device environment still needs its own protection.

This does not mean every small organisation needs to issue hardware security keys to every person immediately.

The appropriate authentication design should consider the people involved, device types, recovery arrangements, licensing and the sensitivity of the resources being protected. Organisations that still rely on SMS or voice should also identify those accounts and plan their migration before Microsoft’s February 2027 retirement date rather than waiting until the existing authentication method stops being available through Microsoft.

For privileged administrators, stronger authentication deserves particular attention because those accounts can make changes affecting other users, applications and security controls.

MFA is also only one security layer. It does not make an unmanaged device trustworthy, prevent every malicious application consent request, replace email filtering or provide a backup of business data.

Microsoft provides Security Defaults as a baseline identity protection option for Microsoft Entra environments that are not using more granular Conditional Access policies.

Where the appropriate Microsoft Entra licensing is available, Conditional Access provides more control over when and how people, devices and applications can access organisational resources.

Conditional Access can consider signals such as:

• • the person or group signing in
  • the resource being accessed
  • authentication strength
  • device compliance
  • device platform
  • other conditions supported by the Microsoft Entra configuration

This makes it possible to require different controls for different situations rather than treating every sign-in identically.

However, Conditional Access is powerful enough to cause widespread access problems when configured incorrectly.

Microsoft recommends testing new policies before enforcement, including using report-only mode where appropriate. Emergency access accounts must also be excluded from policies that could prevent their use during the incident they are intended to recover from.

Security Defaults and Conditional Access should not simply be treated as two security switches that are both enabled independently. An organisation moving to Conditional Access should ensure that the protections previously provided by Security Defaults are deliberately replaced by the required policies.

Identity security is not only about passwords and MFA. Older authentication methods and third-party applications can create additional ways to access Microsoft 365 data.

Legacy authentication protocols do not support modern security controls in the same way as current authentication methods and should normally be blocked once genuine dependencies have been identified.

Older printers, scanners, applications and automated processes should be checked before restrictive policies are enforced. Where a legitimate system still relies on an outdated authentication method, the preferred direction is normally to update, reconfigure or replace that dependency rather than leaving broad legacy access enabled indefinitely.

Third-party application consent also deserves separate attention.

Cloud applications, AI services, CRM platforms, backup products and other tools may request permission to access Microsoft 365 information.

The important question is not only whether the application itself is genuine. The permissions it is asking for also matter.

Microsoft recommends restricting user consent rather than allowing unrestricted approval of applications. Microsoft now provides a managed consent policy that is updated according to its current recommendations. Organisations can also apply more restrictive consent policies where appropriate, including controls based on verified publishers and the permissions being requested.

An admin consent workflow can provide a controlled route for people to request an application when the requested permissions require administrative review.

Existing application permissions should also be reviewed periodically. Changing consent policy does not automatically remove permissions that were granted previously.

Some phishing attacks do not attempt to steal a Microsoft 365 password at all.

In a consent-phishing attack, a person can be taken to a genuine Microsoft-hosted consent screen and persuaded to grant a malicious application access to email, files, contacts or other organisational information. The Microsoft sign-in or consent page itself may therefore be genuine even though the application requesting access is not appropriate.

This changes what people need to look for. A familiar Microsoft page is not by itself proof that the requested access is safe. The application, publisher and permissions being requested still need to be considered.

Microsoft 365 email security extends beyond the tenant itself. The organisation’s public domain and DNS configuration also form part of the security model.

For domains used with Microsoft 365, SPF, DKIM and DMARC should be configured correctly.

These mechanisms perform different jobs:

• • SPF identifies systems authorised to send email for the domain.
  • DKIM applies a cryptographic signature that receiving systems can validate.
  • DMARC checks whether authentication aligns with the visible sending domain and provides a policy for messages that fail those checks.

The complete sending environment should be understood before stricter SPF or DMARC policies are introduced.

Email authentication does not establish that every message which passes authentication is trustworthy.

An attacker can register a separate domain that closely resembles a legitimate organisation and configure valid SPF, DKIM and DMARC records for it. Microsoft describes this as domain impersonation and specifically identifies subtle character changes, including Unicode characters that resemble ordinary Latin letters, as techniques that can make a malicious domain appear familiar at a glance.

This is one reason email protection cannot rely on SPF, DKIM and DMARC alone. Those controls help establish whether a message is authorised by the domain it actually came from; they do not establish that a similar-looking domain genuinely belongs to the organisation the recipient thinks it represents.

Email may also be generated by website forms, CRM platforms, accounting systems, marketing services and other suppliers. A DNS change that ignores one of these legitimate services can interfere with normal mail delivery.

A message may also come from a genuine organisation whose account has been compromised. In that situation the sender address and underlying domain can be legitimate, so checking only whether the address looks correct is not enough.

This is one reason phishing protection also considers behaviour, message content, sender intelligence and account-compromise signals rather than relying only on domain authentication.

MTA-STS addresses a different part of email security. It helps protect inbound transport between mail servers against downgrade and interception attacks.

The NCSC recommends deploying MTA-STS carefully, beginning in testing mode and using TLS reporting before progressing to an enforce policy.

MTA-STS is therefore not another sender-authentication mechanism and is not simply a Microsoft 365 tenant switch. It is a separate domain and mail-transport control.

Microsoft 365 includes different levels of email and collaboration protection depending on the subscription.

Microsoft 365 Business Premium currently includes Microsoft Defender for Office 365 Plan 1. Plan 1 provides important protection beyond the built-in Exchange Online controls.

Plan 2 adds additional investigation and response capabilities, including areas such as Threat Explorer, attack simulation training, advanced hunting and automated investigation and response.

Microsoft does not state that every small business must purchase Plan 2.

Evening Computing commonly recommends evaluating Microsoft Defender for Office 365 Plan 2 where email is business-critical and the additional investigation, response and visibility capabilities provide practical value.

This is therefore an enhanced security recommendation rather than a universal Microsoft requirement.

The licence also needs to be configured correctly after purchase. A higher licence does not automatically mean that every relevant protection has been reviewed, assigned or monitored.

Phishing messages can also move the malicious interaction away from the email itself. QR codes are one example: scanning a code can transfer the person from a business computer to a mobile device and open a phishing site there.

Microsoft Defender for Office 365 provides capabilities for identifying and investigating URLs embedded within QR codes. Defender for Office 365 Plan 2 also supports QR-code payloads and training scenarios through Attack Simulation Training, allowing organisations to include this type of attack in security awareness exercises.

Account security alone does not establish whether the computer or mobile device accessing company information is in an acceptable state.

A person may successfully complete MFA while using a computer that is out of date, unencrypted, poorly configured or no longer under organisational control.

The NCSC recommends the use of managed device controls and describes Mobile Device Management as a way for organisations to remotely control, monitor and enforce policies on devices.

In a Microsoft 365 environment, Evening Computing highly recommends considering Microsoft Intune as the Microsoft-native management platform for business devices.

This turns many device security requirements from informal instructions into centrally managed policies whose status can be checked.

Depending on the platform and organisation, Intune can be used to manage areas such as:

• • device enrolment
  • encryption
  • security configuration
  • Microsoft Defender settings
  • firewall settings
  • Windows security baselines
  • compliance requirements
  • operating system and application management
  • application deployment
  • Windows Hello for Business
  • restrictions around organisational data
  • configuration policies

The benefit is not simply that a setting can be enabled.

The organisation can define an expected configuration, deploy it centrally, monitor whether devices receive the policy and identify devices that do not meet the required state.

This is particularly useful where several computers access the same Microsoft 365 environment and security is expected to remain consistent over time.

Policies still need testing. Device management that breaks legitimate applications or prevents necessary work without understanding the consequence is not automatically good security.

Microsoft Intune and Microsoft Entra can work together so that device condition becomes part of the decision about access to organisational resources.

Intune compliance policies can assess whether managed devices meet defined requirements. Microsoft Entra Conditional Access can then use that compliance result when deciding whether access should be allowed.

This adds a different question to the sign-in process.

MFA helps answer:

Can the person signing in provide the required authentication?

Device compliance can additionally help answer:

Does the device meet the organisation’s requirements for accessing this resource?

Those are not the same question.

A correctly authenticated employee may still be using a device that no longer meets the required security state.

Requiring device compliance should therefore be planned rather than enabled blindly. Devices need to be properly enrolled, compliance policies need to exist, and at least some compliant devices should be available before access restrictions are enforced.

Microsoft recommends testing Conditional Access policies before moving them from report-only to enforcement.

It is important not to imply that Microsoft Defender for Endpoint Plan 2 is the only way a small business can obtain serious endpoint protection.

Microsoft Defender for Business is specifically designed for small and medium-sized organisations and is included with Microsoft 365 Business Premium.

Defender for Business already includes substantial capabilities, including attack surface reduction, an optimised form of endpoint detection and response, automated investigation and remediation and centralised management.

Microsoft Defender for Endpoint Plan 2 extends the available capabilities further. Microsoft’s current comparison identifies additional Plan 2 capabilities and entitlements, including longer data retention and Microsoft Threat Experts.

Defender for Business already provides substantial endpoint detection, investigation and response capabilities, including optimised EDR, automated investigation and remediation, automatic attack disruption and live response actions.

Evening Computing therefore recommends comparing Defender for Business and Defender for Endpoint Plan 2 against the organisation’s actual requirements rather than assuming that Plan 2 is necessary simply because it is the higher product tier.

Where the additional Plan 2 capabilities provide operational value, Evening Computing may recommend Defender for Endpoint Plan 2 as the appropriate endpoint layer.

Where those capabilities are not required, Defender for Business may already provide a substantial endpoint security platform for a small organisation.

The correct choice depends on the required capability, not only the product tier.

Microsoft 365 provides resilience, retention, recycle bins, version history and other recovery mechanisms. These are useful but should not automatically be treated as the complete backup strategy for business-critical data.

The NCSC specifically advises organisations using cloud services not to rely solely on version history or short-term deleted-item recovery for critical information. It recommends keeping an independent copy in another safe place or service.

Microsoft also provides Microsoft 365 Backup as a separate backup service.

Where Microsoft 365 contains important business information, Evening Computing generally recommends a separate third-party Microsoft 365 backup service as an additional recovery layer.

This is an Evening Computing implementation recommendation based on the wider principle of keeping an independent recovery copy. It is not a claim that the NCSC requires a particular commercial backup product.

The backup scope should reflect the services actually used and may include:

• • Exchange Online
  • OneDrive
  • SharePoint
  • Teams-related SharePoint data where applicable

The arrangement should also consider:

• • retention
  • protection of backup administrator access
  • what happens after a Microsoft 365 account is deleted
  • recovery of individual files and messages
  • mailbox or site recovery where supported
  • monitoring of failed or incomplete backups
  • periodic restore testing

Synchronisation is not the same as backup.

If a file is deleted or changed and that change is synchronised through OneDrive or SharePoint, synchronisation has performed its intended function. A separate backup layer exists to provide another recovery position.

A successful backup status also does not prove that the required data can be restored correctly. Recovery should be tested.

Backup is also only one part of recoverability. If Microsoft 365 is central to the organisation’s email, files and administration, continuity also depends on being able to regain administrative control, access important recovery information and continue essential work while restoration is taking place.

A simplified recovery path is:

Something goes wrong
↓
Contain the affected account, device or service where possible
↓
Confirm administrative and emergency access
↓
Identify what information or configuration has been affected
↓
Restore clean information where necessary
↓
Recover normal access and operation
↓
Review what happened and improve the controls

This is why emergency access accounts, protected backup administration, useful audit information and tested restoration should be considered together rather than as unrelated controls.

Security controls have more value when important activity can be identified and reviewed.

Auditing should be verified rather than assumed. The availability, configuration and retention of audit information can depend on the Microsoft 365 services and licensing in use, and Microsoft can change product behaviour over time.

When a tenant is configured or reviewed, confirm that the audit and security information required by the organisation is actually being recorded and can be accessed when needed.

Useful areas to monitor can include:

• • changes to administrator roles
  • use of emergency access accounts
  • unusual sign-ins
  • application consent
  • mailbox forwarding changes
  • suspicious inbox rules
  • security alerts
  • device security incidents
  • compliance failures
  • changes to important policies

Logging does not prevent an incident on its own.

Its value is visibility. It can help establish what happened, when it happened, which identity was involved and what else may need to be checked.

Security monitoring also needs ownership. Buying a product that produces alerts has limited value if nobody reviews the alerts or understands who is expected to respond.

A Microsoft 365 environment changes as people join, leave, change roles, work with suppliers and start using new applications.

Access that was appropriate when it was first granted may no longer be needed later.

The NCSC recommends reviewing who has access to important organisational accounts and removing access that is no longer required.

In Microsoft 365, periodic review should consider areas such as:

• • former staff accounts
  • guest users
  • administrator roles
  • shared mailboxes
  • mailbox delegation
  • SharePoint external sharing
  • OneDrive shared links
  • Teams guest access
  • enterprise applications
  • application consent
  • service accounts
  • suppliers and external collaborators

External sharing itself is not automatically a security failure.

Microsoft 365 is designed for collaboration. The important point is that access remains intentional and still has a current business reason.

Microsoft licensing can make security planning confusing because several controls are included inside larger subscriptions while others are separate products or upgrades.

The security requirement should be defined before deciding which subscription provides it.

Microsoft 365 Business Premium currently includes:

• • Microsoft Entra ID Plan 1
  • Microsoft Intune Plan 1
  • Microsoft Defender for Business
  • Microsoft Defender for Office 365 Plan 1

Additional Microsoft security licensing can provide higher tiers such as Defender for Office 365 Plan 2 and Defender for Endpoint Plan 2.

That does not automatically mean Business Premium plus an additional security package is the most economical configuration for every small business.

A business may need a different combination depending on:

• • number of people
  • number and type of devices
  • whether desktop Microsoft 365 applications are required
  • existing licences
  • required email-security capabilities
  • required endpoint capabilities
  • identity and Conditional Access requirements
  • country and regional pricing

Microsoft licensing and pricing can also change.

For this reason, Evening Computing’s preferred approach is to identify the required technical controls first and then compare the available licensing options.

A bundle should not determine the security architecture simply because it contains many products.

Likewise, purchasing several products separately is not automatically cheaper.

The correct comparison is between the capabilities the organisation actually needs and the licensing routes available at the time.

A Microsoft 365 security design is easier to understand when the underlying guidance is separated from additional implementation choices.

It can also help to view the environment as several connected security questions:

Identity and administrator access
Who is allowed in, and who can make important changes?
↓
Authentication
How does the service establish that the person signing in should be trusted?
↓
Devices and applications
From which devices and applications should access be allowed?
↓
Permissions and sharing
What can each identity, application or external collaborator reach?
↓
Email and domain protection
How are messages, domains and email transport protected?
↓
Monitoring and audit
How would unusual or unauthorised activity be identified?
↓
Backup and emergency access
How can information and administrative control be recovered?
↓
Business continuity
How does the organisation continue operating while a problem is being contained or recovered?

No one layer answers all of these questions. The purpose of the Microsoft 365 security design is to make the layers work together and to keep the access between them intentional.

Controls grounded directly in Microsoft or NCSC guidance

For a small organisation, the underlying direction includes:

• • individual work accounts rather than shared identities
  • least-privileged administrative roles
  • separation between everyday work and administrator activity
  • at least two Microsoft emergency access accounts for tenant recovery
  • multi-factor authentication
  • stronger phishing-resistant authentication for privileged Microsoft administrator roles
  • deliberate use of Security Defaults or Conditional Access
  • blocking unnecessary legacy authentication
  • controlled application consent
  • SPF, DKIM and DMARC for the email domain
  • managed control of organisational devices
  • an independent backup of critical cloud data
  • verification of auditing and security visibility
  • periodic review of accounts and access

Additional implementation layers Evening Computing commonly recommends

Depending on the organisation, Evening Computing may recommend:

• • Microsoft Intune as the Microsoft-native device management platform
  • Conditional Access using Intune compliance information where appropriate
  • Microsoft Defender for Office 365 Plan 2 where its additional investigation and response capabilities are useful
  • Microsoft Defender for Endpoint Plan 2 where its additional endpoint capabilities are justified over Defender for Business
  • a separate third-party Microsoft 365 backup service
  • MTA-STS and TLS reporting where the email environment supports safe implementation
  • periodic technical review of tenant, device, application and recovery configuration

This distinction prevents a particular product from being presented as though it were an official requirement when it is actually one implementation choice.

The appropriate configuration still depends on the organisation.

A sole professional working from one managed computer does not have the same environment as a twenty-person organisation using several Microsoft 365 services, external collaborators, remote staff and multiple business applications.

The principles can remain similar while the implementation stays proportionate.

No Microsoft 365 configuration can guarantee that a security incident will never occur.

Keeping Microsoft 365 applications, operating systems and managed devices supported and updated remains important because known security fixes should be applied. However, fully updated and correctly configured does not mean invulnerable. Complex cloud services, operating systems, browsers, applications and security products can contain vulnerabilities that have not yet been identified, weaknesses for which a fix is not yet available, or faults that affect availability even where no security compromise has occurred.

Microsoft 365 also depends on services outside an individual tenant administrator’s direct control. An organisation therefore needs to consider not only how an incident might be prevented, but how important work could continue or recover if an account, device, application, supplier or cloud service became unavailable.

MFA can reduce the value of a stolen password, but it does not make every device, application or browser session trustworthy.

Separate administrative accounts reduce the exposure of privileged identities, but they still need strong authentication and appropriate use.

Conditional Access can restrict access, but incorrect policies can also block legitimate work if they are not tested carefully.

Defender for Office 365 can identify and block many email threats, but it cannot make every message trustworthy.

Intune can centrally manage device configuration, but it does not remove the need for appropriate policies, supported hardware, maintained operating systems and sensible use.

Endpoint protection can help detect and respond to suspicious activity, but it does not replace identity security, email protection or backup.

A backup provides another recovery position, but only if the required information is included and restoration works when needed.

Effective Microsoft 365 security is therefore layered.

A useful resilience model is:

Prevent → Detect → Contain → Recover → Learn → Improve

Some controls reduce the likelihood of an incident. Others provide visibility when something unusual happens. Access controls and account actions can help contain a problem. Emergency administration and independent backups help provide recovery options.

Recovery should then be followed by review. If an account, application, device or security control did not behave as expected, the organisation should understand why and improve the configuration or process before simply returning to the previous state.

The enduring principles may remain similar, but Microsoft products, licensing and implementation details continue to change. Tenant configuration should therefore be reviewed periodically and when there are significant changes to people, devices, applications, suppliers, licensing or business requirements.

The following primary sources support the main technical principles described in this guide. Microsoft services and guidance can change, so current documentation should be checked before implementation.

The references below are external and open in a new browser tab.

Microsoft identity and administration

• Microsoft: Admin account security in Microsoft 365 for business
• Microsoft: Assign admin roles in the Microsoft 365 admin centre
• Microsoft: Subscriptions, licences, accounts and tenants for Microsoft cloud offerings
• Microsoft Entra: Manage emergency access admin accounts
• Microsoft Entra: Require phishing-resistant MFA for administrator roles
• Microsoft Entra: Passkeys (FIDO2) authentication method
• Microsoft Entra: Passkeys by default and retirement of Microsoft-provided SMS and voice authentication
• Microsoft Entra: Plan a Conditional Access deployment
• Microsoft Entra: Security Defaults

Applications and consent

• Microsoft Entra: Configure user consent to applications
• Microsoft Entra: Manage app consent policies
• Microsoft Entra: Admin consent workflow
• Microsoft Entra: Protect against consent phishing

Email and Microsoft Defender

• Microsoft Defender for Office 365 overview
• Microsoft Defender for Office 365: Anti-phishing protection
• Microsoft Defender for Office 365: Get started using Attack Simulation Training

Devices, auditing and backup

• Microsoft Defender for Business overview and comparison with Defender for Endpoint
• Microsoft Intune: Device compliance policies
• Microsoft Intune: Conditional Access and Intune
• Microsoft Purview: Turn auditing on or off
• Microsoft: Set up Microsoft 365 Backup

NCSC guidance

• NCSC: Protecting your admin accounts
• NCSC: Securing your users’ accounts
• NCSC: Mobile Device Management
• NCSC: Back up your organisation’s critical data
• NCSC: Using MTA-STS to protect the privacy of your emails

The following Evening Computing guides provide more detail on several of the controls covered on this page.

• Email validation and security explained
• What is layered security and why does it matter?
• Cloud Storage vs Backup: Why Sync Is Not Backup
• How YubiKeys work and how to configure them in Intune and Entra ID
• Are passkeys and security keys the same thing?

A guide can explain the principles, but Microsoft 365 security settings affect live accounts, email, permissions, devices and business data.

Evening Computing can help review an existing Microsoft 365 environment or plan a new tenant configuration, identify which controls are relevant, compare licensing routes and advise on suitable next steps before organisation-wide changes are made.