Microsoft 365 has built-in security. Whether it produces a defensible posture depends entirely on how it is configured.
Most Australian organisations using Microsoft 365 are paying for security capabilities they have not fully deployed. Conditional Access, Entra ID Protection, phishing-resistant MFA and Defender for Office 365 are all available within standard licensing. The gap is configuration depth and enforcement consistency, not technology.
See the moments that reveal the gapsWhat Microsoft 365 security actually includes; how Conditional Access works and why it matters; what phishing-resistant MFA requires; and where Australian organisations most commonly fail in their M365 security posture. What gets reviewed and uplifted: how BEC exploits M365 misconfiguration; Conditional Access policy design and implementation; Entra ID hardening and identity protection; phishing-resistant MFA for Essential Eight ML2 privileged accounts; and Microsoft Secure Score improvement.
Most organisations do not discover their Microsoft 365 security gaps by reviewing configuration documentation. They discover them when something external forces the question.
These are the situations Inlight IT most commonly sees prompting a security review.
An email-based fraud attempt against an executive or finance team member reveals that impersonation controls, anti-phishing policies or MFA configuration were weaker than assumed.
Cyber insurance renewal questionnaires now ask specifically about MFA type, Conditional Access policies and legacy authentication status. Many organisations cannot answer these questions with confidence.
An evidence-based Essential Eight assessment identifies that privileged accounts are not using phishing-resistant MFA, or that legacy authentication has not been fully blocked, preventing ML2 on the MFA strategy.
The Secure Score has not improved for months. The remaining recommended actions involve Conditional Access policy changes, and the team is not confident making those changes without understanding the downstream impact.
A review of Entra ID roles finds permanent Global Administrator assignments, accounts with mailboxes holding privileged roles, or admin accounts that are also used for everyday work.
The capability gap in M365 is almost always a configuration gap, not a licensing gap.
Most Australian organisations on Microsoft 365 Business Premium or E3 have access to a substantial set of security capabilities. Conditional Access, Defender for Office 365, phishing-resistant MFA enforcement and Intune device management are all available. Whether those capabilities are producing a defensible posture depends on whether they have been configured, tested and maintained.
Microsoft Secure Score measures the gap between what is available and what is actually configured. In most environments Inlight IT reviews, Secure Score sits well below what the licence supports. Conditional Access policies exist but do not cover all applications. Legacy authentication has not been fully blocked. Privileged accounts are not using phishing-resistant MFA.
The most actionable question is not which licence tier the organisation is on. It is what is deployed, what is partially configured and what is missing entirely. Those three categories drive the engagement scope.
Where capability typically sits in a Business Premium or E3 environment:
- Usually deployed — Conditional Access with some policies in place, Microsoft Authenticator MFA for most users, Defender for Office 365 Plan 1 with default policies and basic Intune enrolment for company devices.
- Usually undeployed or incomplete — Conditional Access coverage across all applications (not just M365), legacy authentication blocking, phishing-resistant MFA for privileged accounts, anti-impersonation policy configuration, application consent governance and break-glass account setup.
- Outside standard M365 licensing — Full Identity Protection risk policies (Entra ID P2 / E5), Privileged Identity Management, extended detection and response across non-Microsoft platforms and SOC-grade monitoring. These require additional investment beyond Business Premium or E3.
Not a single setting. A set of if-then policies evaluated at every sign-in attempt.
Conditional Access evaluates a set of signals at every sign-in attempt and applies the appropriate access control based on policy. It is not a single setting. It is a set of if-then policies: if this user, in this context, accessing this application, meets these conditions, then grant or block access with these controls applied.
How Conditional Access evaluates a sign-in:
At sign-in, Entra ID evaluates available signals: who is the user, what group or role do they hold, what is their sign-in risk level, is the device compliant, where is the request coming from and what application is being accessed.
The signal set is matched against Conditional Access policies. Each policy defines its own conditions and controls. Multiple policies can apply to a single sign-in. The most restrictive applicable policy determines the outcome.
The result is an access grant with controls applied (require MFA, require compliant device, apply session restrictions), a block, or a redirect to complete a requirement (MFA challenge, password reset, terms of use).
What Conditional Access can enforce:
- Require MFA for specific users, groups, roles or applications
- Require device compliance (Intune-enrolled, patched, encrypted) before granting access
- Block access from locations outside approved countries or named IP ranges
- Block or restrict legacy authentication protocols that cannot perform modern MFA
- Require phishing-resistant authentication (FIDO2, certificate-based) for privileged roles
- Trigger step-up authentication when sign-in risk or user risk exceeds a threshold (requires Entra ID P2)
The two main components of a policy:
- Assignments — Who the policy applies to (users, groups, roles), what cloud applications it covers, what device platforms are in scope, what locations are included or excluded and what client apps (browser, mobile, Exchange ActiveSync) are covered.
- Access controls — What happens when the conditions are met: grant access (with or without additional controls), block access or require a session control. Grant controls can require MFA, device compliance, hybrid Azure AD join, approved client apps, or combinations of these.
The type of MFA determines what attacks it can and cannot stop.
Multi-factor authentication reduces the risk of credential compromise, but only if the method chosen is resistant to the attacks being used. The Essential Eight's MFA strategy at ML2 requires phishing-resistant MFA for privileged accounts and enforced MFA across internet-facing services for all users. The type of MFA matters: SMS OTP and standard push notifications satisfy a basic MFA requirement but do not satisfy the phishing-resistant requirement for privileged accounts at ML2.
The distinction matters because adversaries use adversary-in-the-middle (AiTM) techniques that intercept session cookies after a successful MFA challenge, effectively bypassing the MFA step entirely. Phishing-resistant methods bind authentication to the specific domain and device, making AiTM attacks technically ineffective.
MFA methods compared:
Hardware keys (YubiKey, Feitian) that bind authentication to the specific site being accessed. Cannot be phished or intercepted. Required for Essential Eight ML2 privileged accounts. Best option for highest-privilege roles.
Uses a certificate on a compliant device to authenticate. Domain-bound, cannot be replayed against a different service. Suitable for hybrid environments with PKI infrastructure already in place.
Push notifications with number matching and additional context resist MFA fatigue attacks. Still vulnerable to AiTM session hijacking. Does not satisfy Essential Eight ML2 phishing-resistant requirements for privileged accounts, but is appropriate for standard users.
Vulnerable to SIM swapping, interception and social engineering. Does not satisfy Essential Eight ML2 requirements for any account. Should be disabled in favour of app-based or phishing-resistant methods across the entire tenant.
Entra ID is the identity foundation. How it is configured determines what the rest of M365 security can achieve.
Microsoft Entra ID (formerly Azure Active Directory) is the identity and access management platform underpinning every Microsoft 365 service. Every authentication request, every application access decision and every Conditional Access policy runs through Entra ID.
Entra ID hardening is not a single action. It is a set of configuration disciplines that together reduce the attack surface available to an adversary who has obtained valid credentials.
Key Entra ID hardening controls:
Requires privileged role activations to be time-limited, approved and audited. No permanently assigned Global Administrator roles. PIM requires Entra ID P2 licensing (included in M365 E5).
Calculates user risk and sign-in risk scores based on signals including credential leak detection, impossible travel and anomalous sign-in patterns. Conditional Access policies can respond automatically to elevated risk.
Legacy protocols (Basic Auth, SMTP AUTH, IMAP, POP3) cannot perform modern MFA. Any tenant that still permits legacy authentication has an authentication path that bypasses every Conditional Access policy.
OAuth application consent grants are a common persistence mechanism. Users who have been phished into granting consent to malicious apps provide the attacker with delegated access that survives password resets.
Emergency access accounts that bypass all Conditional Access policies must be correctly configured, stored securely and monitored for any sign-in activity. Their absence is a governance risk. Their mismanagement is a security risk.
None of these are obscure. Most are present even in organisations that believe their M365 security is well-configured.
These are the patterns Inlight IT encounters in Microsoft 365 environments during security reviews.
Policies applied to Microsoft 365 applications but not to third-party SaaS applications connected via Entra ID SSO. Attackers target the uncovered applications as the entry point to the wider identity posture.
Basic Auth connections from older email clients or line-of-business applications are still permitted. Every active legacy authentication path is an MFA bypass. The fix requires auditing what is still using these protocols before blocking them to avoid service disruption.
Microsoft Authenticator push notifications are used for Global Administrators and other privileged roles. This does not satisfy Essential Eight ML2. Privileged accounts require FIDO2 or certificate-based authentication. The configuration change is straightforward. The credential rotation that follows is the harder part.
Third-party OAuth applications with delegated permissions have been consented to by users over time. Some of these grants provide read access to mail, calendar and files that persists independently of the user's MFA status. Most tenants have never audited their application consent grants.
Security defaults are still enabled alongside Conditional Access policies. The interaction between the two creates unpredictable behaviour and gaps in enforcement. Security defaults should be disabled when Conditional Access policies are deployed.
Entra ID Protection is generating user risk and sign-in risk signals, but no Conditional Access policies are configured to respond to them. The platform is detecting credential compromise indicators. The organisation is not acting on them.
If you cannot say with confidence which of these patterns are present in your tenant, that is the gap itself — a scoped review finds them before an attacker does.
See how a Cyber Security Review works →The investment required is in configuration, testing and enforcement discipline, not in licensing upgrades.
The Essential Eight's MFA strategy at ML2 requires phishing-resistant MFA for privileged accounts and standard MFA for all other users accessing important data systems. For organisations on Microsoft 365 Business Premium or E3, the licensing for this is already in place through Entra ID P1 and Microsoft Authenticator.
The same applies to the patch management strategy for Microsoft 365 applications: Intune-managed automatic update policies satisfy the Essential Eight's application patching requirements for M365 applications. And Microsoft Defender for Business, included in Business Premium, provides the EDR capability required for the application control and endpoint detection aspects of the framework.
The gap between an M365 environment that satisfies Essential Eight ML2 on identity and one that does not is almost always a configuration gap, not a platform gap.
M365 and Essential Eight ML2 — what maps where:
- Multi-factor authentication strategy — Entra ID Conditional Access with phishing-resistant MFA (FIDO2 or CBA) for privileged accounts. Microsoft Authenticator with number matching for standard users. Legacy authentication blocked. Covers the ML2 MFA requirement in full.
- Restrict administrative privileges — Privileged Identity Management (E5) or documented time-limited role assignment processes (E3/Business Premium). Global Administrator role assigned only to break-glass accounts when not actively needed. Separate admin accounts with no mailbox.
- Patch applications (M365 apps) — Microsoft 365 Apps update channel configured via Intune or Group Policy. Current Channel or Monthly Enterprise Channel with automatic updates enabled and verified. Supports Essential Eight patching requirements for the M365 application set.
- User application hardening — Defender for Office 365 with Safe Links, Safe Attachments and anti-phishing policies. Office macro settings configured to block macros from the internet. Attack Surface Reduction rules via Defender for Business.
Microsoft 365 security hardening, sequenced and tested before enforcement.
The engagement starts with an audit of the current Conditional Access estate: what policies exist, what they cover and where the gaps are. Conditional Access changes are tested in report-only mode before enforcement. Legacy authentication is audited before blocking. Privileged role MFA is uplifted with a credential rotation and FIDO2 or CBA deployment. The outcome is a tighter identity posture, stronger MFA enforcement and fewer unmanaged access paths.
Every existing policy reviewed for scope, gaps and enforcement mode. Applications without CA coverage identified. Report-only mode used to test new policies before enforcement.
All active legacy auth connections identified before blocking. Shutdown sequenced to avoid service disruption. Modern auth alternatives confirmed for any remaining legacy clients.
Privileged accounts moved from push-notification MFA to FIDO2 or certificate-based authentication. Permanent Global Administrator assignments reviewed and PIM-eligible roles configured where applicable.
OAuth delegated permissions reviewed. Over-permissioned third-party app consents revoked. Admin consent policies configured to prevent future uncontrolled grants.
Emergency access accounts confirmed to be correctly configured, stored securely and monitored. Sign-in alerts on break-glass accounts set up if not already in place.
Active monitoring for unexpected access failures or policy gaps following enforcement changes. Rollback process confirmed before enforcement begins.
M365 security can be a discrete hardening engagement, or the entry point to a wider operating conversation. The right route depends on what the posture review reveals.
For some organisations, the immediate need is a focused M365 security uplift — audit the Conditional Access estate, block legacy authentication, deploy phishing-resistant MFA on privileged accounts, clean up application consent grants. That is the engagement this page describes. It is a discrete piece of work with a defined deliverable.
For other organisations, M365 security is not a one-time hardening exercise. It is an operating discipline that has to continue once the initial configuration is in place. Conditional Access policies drift over time as new applications are added. Privileged role assignments accumulate. New OAuth consents get granted. Entra ID Protection signals need someone to act on them. That ongoing operating discipline is part of Managed Cyber Security — the service that provides the deeper security operating layer above the managed IT baseline.
The practical question — “is the immediate need a discrete hardening engagement, or an ongoing operating layer, or both?” — is the conversation a Cyber Security Review is built to surface. The review establishes current posture across Conditional Access, identity, MFA enforcement, legacy authentication and application consent, identifies the gaps that matter most commercially, and clarifies whether the right next step is the discrete hardening engagement, the ongoing managed cyber security service, or both.
This page covers what M365 security includes and what the hardening engagement looks like. The conversation about scoping the right next step starts with the Cyber Security Review.
The Inlight IT view on M365 security.
Microsoft 365's built-in security is a strong foundation. Whether it produces a defensible posture depends entirely on how the organisation has configured it.
For most Australian organisations on Business Premium or E3, the licensing gap is not the problem. The configuration gap is. Most of what is required for Essential Eight ML2 on identity and email is already licensed. The failure point is consistently the same: Conditional Access policies that do not cover every application, legacy authentication that has not been fully blocked, and MFA methods that do not satisfy phishing-resistant requirements for privileged accounts.
The organisations that get M365 security right are not the ones with the most expensive licensing tier. They are the ones that have worked through the configuration disciplines methodically: audited what legacy authentication is still active, enforced Conditional Access across every application, and deployed phishing-resistant MFA for the accounts that matter most. That work is engineering, not procurement.
Platform capability is the benefit. Configuration depth and enforcement consistency are the trade-off.
Questions Australian IT managers and security buyers ask when researching M365 security configuration.
What is Conditional Access in Microsoft 365?
Is Conditional Access the same as MFA?
Is Conditional Access better than security defaults?
Is Microsoft 365 vulnerable to attack?
What is a user risk in Microsoft Entra ID Protection?
Is MFA required by law in Australia?
Can I still be hacked with MFA enabled?
How is M365 security delivered by Inlight IT?
Find out where your M365 posture actually sits — then scope the right next step.
See which gaps matter most before fixing anything.
Discuss your cyber security position