Microsoft 365

There is a specific and repeatable finding in tenant assessments: a large share of the security capability included in the customer's existing licence is either unconfigured or left at defaults that were designed for the smallest possible customer, not for an enterprise.

Common examples are unglamorous and high-impact. Safe Links and Safe Attachments not enabled, or enabled without the policies that make them useful. Anti-phishing impersonation protection not configured with the executive names it is meant to protect. Legacy authentication protocols still permitted, which quietly bypasses every conditional access policy above them. Audit logging retention left at the minimum. Sensitivity labelling licensed and never deployed.

None of these require a purchase. They require someone to have owned the tenant as a platform rather than as a completed migration, and that ownership is exactly what tends to lapse once the project team disbands and business-as-usual absorbs the work.

This is why we audit entitlement before recommending anything. It is frequently the case that an E3 tenant, properly configured, closes more real risk than an E5 upgrade deployed at defaults - and we would rather tell you that than sell an uplift. When E5 genuinely pays for itself, the case is easy to make with evidence from your own environment.

Teams and SharePoint were designed to make creation frictionless, and they succeeded. The consequence is that most mature tenants contain thousands of sites and teams, a significant proportion of which have no active owner, no retention policy, and no record of why they exist.

The risk this creates is not primarily storage. It is that content with real sensitivity sits in containers whose sharing settings nobody reviews, owned by people who have left, indexed and discoverable by anyone in the organisation - and increasingly surfaced by AI assistants that respect permissions faithfully and therefore reveal exactly how permissive those permissions were.

External sharing deserves particular scrutiny. Default settings frequently permit anyone-with-the-link access that never expires, which means a document shared with a supplier three years ago for a single transaction may still be retrievable by anyone who has that URL, including through a forwarded email nobody remembers.

Fixing this has two halves and both are necessary. The remediation half - inventory what exists, establish or reassign ownership, apply retention and archival, tighten sharing - is finite work. The prevention half - a provisioning model with naming, ownership, expiry and attestation built in - is what stops the sprawl regrowing. Doing only the first means repeating it in three years.

Identity answers who is asking. Device compliance answers whether the thing they are asking from is in a state you would accept. Without the second, a verified user on a compromised, unpatched or personally-owned machine gets the same access as one on a managed device, which undercuts much of the value of the identity work.

Intune compliance policies let access decisions depend on encryption status, OS patch level, jailbreak or root detection, endpoint protection state, and whether the device is enrolled at all. Paired with conditional access, this turns device health from a reporting metric into an enforced precondition.

The hard part is rarely technical. It is the personally-owned device question, which is a policy and employment-relations decision as much as a security one. App protection policies offer a middle path - protecting corporate data within managed applications without enrolling the whole device - and are frequently the right answer for contractors and BYOD populations where full management is neither acceptable nor enforceable.

As with conditional access, we stage this. Compliance policies are deployed in reporting mode to establish the real baseline, remediation is communicated with time to act, and enforcement follows once the population is largely compliant - because a policy that locks out a third of the workforce on day one gets rolled back, and rollbacks are expensive in credibility.

Every capability in Microsoft 365 that people do not use is a line item with no return. This is the least technical part of the engagement and frequently the one with the clearest financial impact, because the licence cost is fixed whether or not anyone opens the application.

Poor adoption usually has identifiable causes rather than being a general reluctance to change. Overlapping tools with no guidance on which to use for what. Migration that moved files without moving the working practices around them. No visible executive use, which tells everyone the change is optional. Training delivered once at rollout, to people who had no context yet for why it mattered.

We treat adoption as a designed activity with measurement attached: usage baselines before and after, targeted enablement for the specific groups and workflows where the change is worth the friction, and a governance model that answers the where-does-this-go question rather than leaving it to individual judgement.

It is also where hardening pays a second dividend. Controls deployed well are largely invisible - single sign-on that just works, protection that catches phishing silently, sharing that is scoped without being obstructive. Controls deployed badly generate friction that people route around, and every workaround is both a security gap and an adoption failure at the same time.