Notes

Microsoft 365 security when the tenant is small and you are alone

A tenant of forty people has the same attack surface as a tenant of four thousand and roughly one percent of the attention. The identity provider is the same. The Conditional Access engine is the same. The consequences of getting locked out are the same. What differs is that there is nobody to check your work, and no second administrator to open a support case on your behalf when you break sign-in for everybody at 4pm on a Friday.

That constraint shapes every note here. Microsoft 365 security at small scale is less about configuring more and more about configuring a defensible minimum, being able to prove it, and not locking yourself out in the process.

What microsoft 365 security looks like without a team

Three things go wrong repeatedly, and none of them are exotic.

Policies that were never finished. A Conditional Access policy named TEST DO NOT ENABLE that has been enabled for two years, because somebody turned it on to check something and the name stopped being read. An Intune compliance policy assigned to All Devices that nobody can explain. Report-only mode exists precisely to avoid this and is skipped because it feels slow.

Privilege that never got taken back. Global Administrator granted for a migration in 2023. A guest invited for a project that finished. An app registration created during an integration trial. Each was correct at the time and nothing in the tenant will ever prompt you about it.

Evidence that was not kept. The access review happened, in the sense that somebody looked, but there is no record of who looked or what they decided. Six months later that is indistinguishable from not having done it, which matters when a customer questionnaire or an auditor asks.

The lockout problem is real

The distinctive risk of running a tenant alone is that you are one bad policy away from having no administrative access, and there is nobody else with the rights to undo it.

That is why break-glass accounts get a note of their own, why report-only mode is worth the extra day, and why every Conditional Access change in these notes comes with the exclusion that keeps you in the building. It is also why "just enable the recommended baseline" is worse advice for a one-person tenant than a ten-person team, because the recovery path assumes a colleague.

Configuration you can diff

The other recurring theme is that portal state is not a record. The Intune blade shows you what a policy says today. It will not tell you what it said last month, which of two hundred settings moved, or who moved it.

Exporting configuration to JSON and committing it solves that for roughly an afternoon of work, and produces configuration management evidence as a side effect. That is the highest ratio of outcome to effort anywhere in this cluster.

Reading order

Conditional Access first, because it is the control with the largest blast radius in both directions. Break-glass immediately after, and honestly it should be read first if you are about to change any policy this week.

PIM, guests and audit retention are independent and can be read in any order. Intune configuration as code sits slightly apart: it is the one that produces evidence rather than reducing risk, and it is the one people are most glad to have when somebody asks what changed.