How do we secure Microsoft 365 against phishing and account compromise?

Why does Microsoft 365 security need more than a spam filter?

An attacker does not need to infect every computer to disrupt a business. Access to one mailbox can reveal supplier conversations, reset links, customer details and the wording colleagues use to approve purchases. A convincing message may arrive from a genuinely compromised contact, so a familiar name does not settle whether a request is safe. Protecting the inbox and protecting the identity behind it are connected jobs.

Think about the whole sequence: the message reaches an employee, the employee follows a link, a sign-in or session is captured, and the attacker uses that access. Different controls interrupt different stages. Email filtering may stop the initial message; stronger authentication may defeat a fake sign-in page; monitoring may reveal unusual use; a payment verification process may prevent money being redirected. This layered approach reduces reliance on one perfect product or one perfectly attentive employee.

Start with a review of your tenant rather than assuming every feature in a subscription is active. NetMonkeys’ Microsoft 365 support services provide a relevant route for examining identity, email configuration and operational support together.

What should we establish before changing security settings?

Record who administers Microsoft 365, which domains send business email, how people sign in and which systems depend on the tenant. Include finance applications, website enquiry forms, scanners, mobile devices and external service providers. A change that seems limited to email can interrupt an old application or an automated workflow if its authentication method has been overlooked.

Agree the business impact of a change, a test group and a recovery route. For example, test a new access requirement with people who use both company laptops and mobile phones before extending it to everyone. Include remote workers and staff who rarely visit an office. An emergency access arrangement should be documented, strongly protected and monitored, with clear responsibility for testing that it still works.

Create a short baseline: privileged accounts, authentication coverage, external forwarding exceptions, security alert ownership and outstanding incidents. Keep the evidence in a controlled administrative record. That baseline allows the business to distinguish a configured policy from an aspiration and makes subsequent reviews less dependent on somebody remembering what was changed.

Which controls address the main attack paths?

Use the table to identify gaps, rather than treating it as a procurement checklist. Several controls require operational decisions as well as technical settings. Someone must decide which suppliers are allowed to send using your domain, who may approve an app and who will respond to a high-confidence alert outside ordinary office hours.

Avoid measuring progress simply by counting enabled features. A stronger result is evidence that a suspicious message reaches a monitored reporting route, that an administrator can contain an affected account, and that finance can verify a changed bank account without relying on the suspect conversation.

How should we strengthen sign-ins without locking people out?

Require multifactor authentication through an approach suited to the tenant and its licences. Where supported and practical, move higher-risk users towards phishing-resistant methods. Microsoft’s authentication strengths guidance explains how Conditional Access can require particular authentication methods; the policy capability requires appropriate Entra licensing.

Do not describe every passwordless or multifactor method as phishing-resistant. Assess the actual method and supported sign-in flow. Registration is also a security event: verify how a new method is added and how a user recovers when a device or security key is unavailable. An attacker who persuades a helpdesk to reset access can undermine an otherwise strong sign-in policy.

Roll changes out in stages and monitor failures. Keep ordinary user accounts separate from privileged administration wherever practical. Administrators should not browse email or perform daily work under an identity with broad tenant powers. Review old authentication dependencies before removing them, then retire exceptions through a tracked plan rather than allowing temporary workarounds to become permanent.

How do Conditional Access and device controls fit together?

An access policy can consider more than the fact that a password is correct. Depending on licensing and configuration, policies can apply requirements connected to authentication, devices, applications and the circumstances of access. Define the outcome first: for example, sensitive business information should be accessed through an approved route with stronger identity assurance.

Test policies against real working patterns. A colleague using a contractor-managed device, a travelling director and a warehouse terminal may require different designs. Exceptions should have a named owner, an explanation and a review date. Avoid broad exclusions for an entire department simply because one unusual workflow is difficult to support.

Device management complements identity security by helping the business control the endpoint used to open company data. It does not make every sign-in safe or remove the need to monitor suspicious behaviour. Plan deployment, support and privacy communication together, particularly where personal devices are involved. Ask which controls your current licence supports and which need an additional subscription before committing to a design.

What email protection should we review?

Review how suspicious messages are detected, quarantined, released and reported. Microsoft distinguishes the anti-phishing capabilities available for cloud mailboxes from additional Defender for Office 365 protections. Its anti-phishing policy documentation is the reference for the relevant features and configuration. Check the purchased plan and the policy actually applied to each user.

Give impersonation-sensitive roles appropriate attention, including senior leaders, accounts payable, payroll and people who change supplier details. Review trusted sender exceptions carefully. An exception introduced to fix one delivery problem can create a wider blind spot if it covers an entire domain or bypasses checks unnecessarily.

Decide how employees request release of a quarantined message and who evaluates that request. A security warning is not useful if normal practice is to override it immediately. Track false positives and genuine threats separately so the business can improve delivery without weakening protection. Keep evidence of policy changes, including why an exception was needed and when it will be reconsidered.

How do SPF, DKIM and DMARC reduce domain impersonation?

These mechanisms help receiving systems assess whether email using your domain is authorised and authenticated. They support domain protection, but they do not establish that every message from a real employee or supplier is trustworthy. A compromised legitimate account can still send a harmful request.

Build a complete list of sending services before tightening policy. Include marketing platforms, billing tools, recruitment systems and the website, as well as Microsoft 365. Work out who controls each sender and whether it is configured correctly. Review reporting and delivery behaviour as enforcement becomes stricter, using an agreed change plan to avoid disrupting legitimate mail.

Give somebody responsibility for maintaining that inventory. When marketing adds a new email service or finance replaces an invoicing platform, email authentication needs to be part of the change. Do not publish generic DNS values copied from a guide: the right records depend on your own domains and authorised senders. A managed configuration review should leave you with an understandable record of what is permitted and why.

Why must we review apps, forwarding and administrator permissions?

Account compromise is not always a password problem. Applications may have permission to read information or act on behalf of a user, and mailbox rules or forwarding can continue exposing correspondence after the original message has been forgotten. Review app consent, delegated access, existing integrations and the business owner for each connection.

Look for external forwarding arrangements and rules that redirect, hide or delete relevant messages. Some forwarding is legitimate, so assess purpose and destination rather than deleting settings without investigation. Make sure leaver processes address sessions, application access and shared resources alongside the ordinary user account.

Review administrative roles regularly and remove powers that no longer match somebody’s work. If an external IT provider has access, document the authorised scope and support arrangement. These reviews are easier when ownership is maintained continuously. NetMonkeys’ managed security services can form part of a discussion about ongoing oversight rather than a one-off configuration exercise.

What should employees do when a message feels wrong?

Provide a simple reporting route inside the tools people already use, backed by an alternative contact method if email itself may be compromised. Tell staff to report suspected phishing even if they clicked, entered information or approved a prompt. Blame makes reporting slower and leaves the response team with less useful evidence.

Use short, realistic examples from business processes: an unexpected shared document, an urgent invoice correction, a director requesting secrecy or a request to change payroll details. Train people to verify unusual instructions through a known independent channel. Looking closely at the sender address helps, but it cannot establish that a legitimate account has not been compromised.

Finance controls deserve explicit ownership. A bank detail change should follow a defined verification process regardless of the sender’s seniority or the apparent continuity of an email thread. Employees need permission to pause a suspicious request. Include new starters, temporary staff and senior leadership in the same expectations, adapting examples to their actual responsibilities.

What should happen if an account may already be compromised?

Have the response handled by a competent administrator or incident response team. Depending on the situation, containment may involve restricting sign-in, revoking sessions and reviewing authentication methods as well as changing credentials. A password reset alone does not answer whether information was accessed or whether another route remains available.

Preserve relevant evidence before making broad cleanup changes. Coordinate technical work with finance, management and any responsible privacy or legal contact. Regulatory and contractual decisions depend on the actual incident and should be assessed by the appropriate owner. Do not promise that every account compromise requires the same notification, or that absence of a visible fraudulent email proves no harm occurred.

How do we know the controls continue to work?

Assign an owner for alert monitoring and define response expectations. A mailbox that receives alerts but nobody checks is not an effective monitoring service. Test notification routing, escalation and access to the administrative tools needed during an incident. Ensure holiday cover and supplier responsibilities are clear.

Use a small operational scorecard: authentication coverage, unresolved high-risk exceptions, unreviewed application grants, time to acknowledge reported messages and completion of incident exercises. Interpret trends with context. A rise in staff reports can indicate improving awareness, while a low report count can reflect either fewer threats or uncertainty about how to ask for help.

Review security after a material business change, including a new acquisition, outsourced process or application integration. Keep recovery and support records current. An annual review is useful, but it cannot substitute for responding when the environment changes. Security should remain a maintained business capability with visible ownership, rather than a collection of settings remembered by one colleague.

How should we prioritise a limited security budget?

Prioritise using exposure and business consequence. An unprotected administrator, an unmonitored forwarding exception and a weak payment-change process are different risks, so comparing them only by project price is misleading. Identify who could misuse the access, what they could reach and whether the business would notice. Give higher priority to weaknesses that allow broad access or affect consequential business activity.

For an illustrative company, the first review might find that finance already uses a careful telephone verification process but several privileged identities lack an agreed recovery and monitoring arrangement. The immediate work could focus on those identities while a broader email policy review follows. Another company might discover unmanaged external forwarding and unclear incident ownership. Its priorities would differ even if the licence inventory looked similar.

Write down why each action comes before another. Include dependencies, employee disruption and the operating effort required after installation. An inexpensive control that nobody maintains can create less value than a slightly larger change with clear ownership. Ask a proposed provider to explain what evidence will demonstrate that the risk has been reduced, rather than accepting an unchecked list of recommended products.

How can we rehearse recovery without disrupting the business?

Use a tabletop exercise based on a fictional compromise rather than experimenting with a live employee account. Give the participants a short timeline: an employee reports entering credentials, a suspicious forwarding rule appears and finance receives an unusual request. Ask each owner what they would do, which evidence they need and who they would contact.

Walk through access to the required tools, out-of-band communication and supplier escalation. Identify gaps such as an incident contact list stored only inside the affected email system or uncertainty about who can authorise containment. Record corrective actions with named owners and repeat the relevant part of the exercise after they are completed.

Separately test approved technical recovery arrangements using controlled identities and a documented plan. The objective is confidence that recovery works, not a dramatic simulation that puts production work at risk. A rehearsal is particularly useful when staff or IT providers change, because assumptions about responsibility can become outdated without any visible change to the tenant.

What is a practical next step for a UK business?

Begin with a focused assessment covering identity, privileged access, email policies, domain authentication, application permissions and response readiness. Ask for findings expressed as business consequences and prioritised actions. A useful recommendation explains what will change, which users are affected, the licence implications and how success will be checked.

For the first improvement cycle, choose a manageable group of changes and document the evidence. That may mean closing an unmanaged forwarding exception, protecting a sensitive administrative role and rehearsing the employee reporting process. Larger controls can follow with a proper rollout plan. The goal is measurable progress that people can operate confidently.

Bring your current licence list, administrative arrangements and a description of recent concerns to a conversation with NetMonkeys. Avoid sending live passwords or unnecessary customer information. The Microsoft 365 team can help connect the configuration work with ongoing support, while security specialists can examine monitoring and response requirements. Agree the scope and acceptance criteria before treating the work as complete.