Mycelium 365 — Managed IT, Microsoft 365 and Azure across Australia, New Zealand and the United States
    Security frameworks

    Zero Trust

    Zero Trust is a security model that assumes no user, device or network location is inherently trustworthy. Every access request is authenticated, authorised and evaluated against current signals such as device compliance and sign-in risk, and users receive the least privilege needed for the task at hand.

    What Zero Trust means in practice

    Zero Trust replaced a model that made sense when everyone worked in one building. The old approach hardened the perimeter and treated anything inside the corporate network as trusted. Once applications moved to the cloud and staff worked from home, that perimeter stopped describing anything real, and a single stolen credential gave an attacker the same implicit trust as an employee at a desk.

    The model rests on three principles. Verify explicitly: authenticate and authorise on every request using all available signals, including identity, device health, location, workload and data sensitivity. Use least privilege access: grant just enough permission, just in time, with risk-based adaptive policy. Assume breach: segment access, encrypt everything, and design monitoring on the basis that an attacker is already inside.

    In Microsoft 365 this is not an abstract architecture. Identity is enforced through Microsoft Entra ID with conditional access as the policy engine. Device health comes from Intune compliance policy, which conditional access can require before granting access to email or files. Threat signal comes from Microsoft Defender XDR across email, endpoint, identity and cloud applications. Data protection comes from sensitivity labels and data loss prevention, which travel with the file rather than depending on where it is stored.

    The most common implementation mistake is treating Zero Trust as a project with an end date. In practice it is a series of policy decisions applied in order: multi-factor authentication everywhere, legacy authentication disabled, device compliance required, privileged accounts separated, then risk-based policies tuned once you have enough telemetry to avoid locking out the business.

    The second most common mistake is deploying policy without exception handling. Break-glass accounts, service accounts and genuine field conditions — a site with no mobile coverage, a shared device on a factory floor — need designed answers, or staff will find workarounds that undo the model.

    How we help with this

    Related terms

    Back to the full glossary

    Ready to simplify and secure your technology?

    Book a free, no-obligation Discovery Call to talk through your Microsoft 365, Azure, security, or support needs — no sales pitch, just a straight conversation.

    We respond to every enquiry within 4 business hours. Monday to Friday, 7am–7pm AEST.