The next phishing wave is not just email. It is identity-led, Microsoft 365-aware and built around finance and supplier workflows.
Attackers increasingly want session tokens, OAuth consent, mailbox access and trusted payment threads, not just passwords. That changes the defence.
Email filtering and awareness training still matter, but they are no longer the centre of the control stack. The work now sits in Conditional Access, phishing-resistant MFA for sensitive roles, OAuth consent governance, mailbox monitoring, DMARC enforcement, device compliance and finance-workflow verification.
Three questions that clarify where phishing has actually moved
What identity-led phishing means, why MFA alone is no longer enough, and how modern BEC actually works.
What does identity-led phishing actually mean?
Techniques that target access tokens, OAuth app consent, or active sessions rather than passwords — device code phishing, adversary-in-the-middle (AiTM) kits, and malicious app consent. These methods can bypass standard MFA because they capture the session itself or trick the user into authorising the attacker's app, rather than stealing a password typed into a fake login page.
Why is MFA alone no longer enough?
Phishing-resistant MFA — FIDO2 security keys, certificate-based authentication — materially reduces risk. SMS, voice and basic push-notification MFA can still be intercepted by AiTM kits or bypassed by device code phishing. For sensitive roles, the control quality matters more than the presence of MFA. The Australian Signals Directorate now explicitly recommends phishing-resistant MFA for high-risk users and online services.
How does modern BEC actually work?
Modern BEC often begins after mailbox access is gained, not before it. The attacker silently observes live conversations, sets hidden inbox rules, watches payment threads, and uses the real account at the right moment to redirect funds. The instruction looks legitimate because it comes from the real address and references real conversations. Spam filters do not catch this — the defence sits in identity controls, mailbox monitoring and finance-workflow verification.
The next phishing wave is identity-first, not inbox-first.
- Targets the password
- Caught by filtering and training
- Question: are users clicking?
- Defence spam filter and awareness
- Targets tokens, consent and sessions
- Built to work around standard MFA
- Question: when a user clicks, what does the stack catch?
- Defence identity policy, consent governance, mailbox visibility, DMARC, finance verification
Six techniques shaping how phishing actually lands.
None of these should be treated as nation-state-only techniques. All are now relevant to SME and mid-market Microsoft 365 environments — some visible in Australian threat reporting at category level, others in current global Microsoft and threat research that closely reflects how Australian organisations operate.
The Australian threat data sits where the work sits. In FY2024-25, the Australian Signals Directorate's Cyber Security Centre recorded email compromise without financial loss as the top self-reported cybercrime threat category for businesses at 19%, and BEC causing financial loss at 11% (Australian Signals Directorate, Annual Cyber Threat Report 2024-25). The threat is concentrated where business operations concentrate. The defence has to sit there too.
A tenant can have MFA, EDR and a reasonable spam filter, and still be exposed to every technique above.
The visible posture and the operational posture are not the same thing. None of these exposures require advanced threat actors — all are exploited at SME and mid-market scale every week in Australia. What is needed is engineering ownership of the configuration and the alerts.
Broad app consent
Users can broadly consent to third-party cloud apps without admin review.
Device code flow never reviewed
Device code authentication flow is enabled tenant-wide and never reviewed.
High-risk users, standard MFA
Admins, finance and executives have the same MFA quality as everyone else.
Risky sign-ins uninvestigated
Sign-ins from unfamiliar geographies or impossible-travel patterns do not trigger investigation.
Payment changes from email alone
Finance and supplier banking changes can be approved from email alone.
DMARC configured, not enforced
SPF, DKIM and DMARC are configured but not enforced at strict policy level.
Mailbox alerts unmonitored
Inbox-rule and mail-forwarding alerts are not monitored or triaged.
Personal devices fully trusted
Personal devices access Microsoft 365 with the same trust as managed devices.
Most damaging BEC engagements do not start in finance. They start with mailbox access on someone nearby.
The compromise that ends in a redirected payment is rarely the first event. It is the result of a sequence the attacker runs over days or weeks, often through a mailbox that does not feel high-risk on the org chart — a project lead, EA or sales contact with broad supplier visibility.
Spam filters do not catch step four. The email is genuine — it comes from the real address, references real conversations, and arrives at the right moment in the workflow. The protection has to come from identity-side detection at step one, mailbox monitoring that surfaces the hidden rule at step two, and finance workflow rules that do not allow payment-detail changes from email alone at step four.
Modern phishing defence is not one product. It is eight controls operating together.
Each control below is an operational layer. None replaces the others. The combination is what reduces real risk for an SME or mid-market Microsoft 365 environment.
Many of these can be improved inside the Microsoft 365 controls organisations already own, although licensing and monitoring requirements vary. If finance can change supplier banking details from email alone, the BEC problem exists before the first phish lands — process discipline is part of cyber defence, not separate from it.
Phishing defence now needs engineering ownership across Microsoft 365.
The Inlight IT view is that phishing defence now needs engineering ownership across Microsoft 365, not just user reminders and email filtering. Conditional Access needs to restrict risky flows. Sensitive roles need stronger MFA. App consent needs governance. DMARC needs enforcement. Mailbox forwarding and inbox-rule changes need monitoring. Personal-device access needs policy. Finance teams need a controlled process for payment and supplier banking changes. A useful review tests the controls attackers now work around — the work is engineering ownership of the configuration and the alerts, not a poster campaign.
If finance can change supplier banking details from email alone, the BEC problem exists before the first phish lands.
Restrict risky authentication flows
Strengthen MFA for sensitive roles
Govern consent and enforce DMARC
Monitor mailboxes and verify payment changes
Where this is delivered.
The value is in the operating stack, not a single product. The same incident may require identity investigation, mailbox review, consent revocation, endpoint checking, finance-process validation and user communication — if those functions sit in separate silos, the response slows down and important evidence is missed. Where the primary exposure is on the BEC and email-fraud side specifically, the Business Email Compromise page covers the prevention and detection layers in more depth.
A scoped review that surfaces the exposure across identity controls, OAuth consent, Conditional Access coverage, mailbox visibility, DMARC enforcement, device trust and finance-workflow discipline.
The hardening engagement covering the Microsoft 365 configuration depth of this work.
Phishing defence layers operated continuously rather than fixed once and left to drift.
Make phishing defence an operating control, not a reminder campaign.
Review identity, email and payment-change controls before phishing becomes operational exposure.
Discuss your cyber security position