Security and identity inside a Microsoft 365 estate

Identity and Microsoft Entra

Entra ID is where a Microsoft 365 estate is actually governed. Users, groups, guest accounts, service principals, app registrations, and the directory attributes that everything downstream reads.

The work is usually one of three things. Understanding what the current model actually is, because it is rarely what the documentation says. Rationalizing it where an estate has accumulated groups and permissions nobody can account for. Or rebuilding it in a target tenant during a consolidation, where the mapping has to be decided before anything moves.

In a hybrid estate this includes on-premises Active Directory, because the two are one identity system rather than two. That means synchronization, which side is the source of truth, what breaks when that changes, and what happens to the on-premises side after a move. Treating the tenant as the whole picture is how a consolidation discovers its real dependencies late.

Zero Trust, MFA and Conditional Access

Conditional Access is the policy layer most estates have some of and few have coherently. Policies accumulate one incident at a time, and the set stops matching the organization it was written for.

The work is reading the policy set as a whole rather than one policy at a time. What is actually enforced, what is exempted and why, which accounts sit outside it, and whether the exclusions meant to be temporary are still there.

MFA coverage is the question underneath it. Not whether MFA is enabled, but which accounts are genuinely covered, which are excluded, and whether the excluded ones are the ones you would least want excluded.

Zero Trust is used here as a design frame rather than a product. Nobody arrives at it, and there is no Zero Trust program to buy.

Endpoint management and Intune

Devices do not follow the mailbox. Intune enrollment, compliance policies, configuration profiles, BitLocker keys and Autopilot registrations are their own estate with their own dependencies.

The work is establishing what is enrolled and what only appears to be, and what compliance policies actually gate access to. During a tenant move it also covers what has to be re-enrolled against the target, and in what order relative to identity.

The Apple side of an estate has the same shape and a less obvious dependency. Apple Business Manager federates to Entra ID rather than to on-premises Active Directory, and the token that hands a device to Intune for automated enrollment is issued against one tenant. A Mac or iPhone that enrolled itself in the source environment does not follow the identity into the target. Devices are released and re-enrolled, and managed Apple Accounts have to be reconciled against whichever directory is authoritative once the move is done.

Data security and Microsoft Purview

Sensitivity labels, data loss prevention, retention, and information protection — the controls that determine what leaves a tenant and what stays recoverable inside it.

Where this matters most is sharing that was never reviewed. Permissions granted years ago to solve one problem, links that outlived the document, and guest access to sites nobody remembers creating. That posture is invisible until something reads across it — which is why it surfaces during consolidation, and why it surfaces again the moment Copilot is switched on.

Native retention is a configuration, not a backup. The two are frequently mistaken for each other.

Security assessments

Assessment work in a Microsoft 365 estate takes two shapes. A bounded engagement — a defined review of tenant configuration against a published baseline, with prioritized findings — is a specific piece of work with its own page.

Microsoft 365 Security Assessment →

The other shape is not an engagement at all. It is what surfaces during migration discovery: standing admin rights nobody re-approved, Conditional Access that stopped matching the estate, MFA gaps, and sharing that was granted once and never reviewed. Those findings arrive whether or not anyone commissioned a security review, and what happens to them is a decision rather than a deliverable.

The bounded engagement and the capability are not the same size. The assessment is deliberately scoped so it can be quoted, delivered and proved. What Sunrise can look at in an engagement is set by the estate. A hybrid identity question, or an application authenticating against Entra ID, is in scope because it is part of the same system — not because the offer was widened.

NIST-aligned security assessments

The NIST Cybersecurity Framework is a way of organizing what a review covers and what it deliberately does not. It gives a common vocabulary when a client, an insurer or a board asks how an assessment was structured.

Where Sunrise uses it, it is used as a frame of reference for Microsoft 365 scope. Identify and Protect map cleanly onto tenant configuration, identity and data controls. Detect, Respond and Recover mostly do not, because they describe an operational capability Sunrise does not provide.

Published by NIST: Cybersecurity Framework →

Aligned means measured against, and nothing more. Sunrise assesses and remediates; it does not certify, accredit or attest, and there is no NIST approval or endorsement to claim.

CISA SCuBA-based configuration review

CISA's Secure Cloud Business Applications baselines are a published, specific set of recommended Microsoft 365 configurations. An open-source tool, ScubaGear, reports how a tenant compares against them.

The value of a published baseline is that it is not Sunrise's opinion. Findings can be checked against a public document by anyone, including whoever disagrees with them.

Published by CISA: Secure Cloud Business Applications (SCuBA) project → · ScubaGear →

Assessment against these baselines is delivered as the Microsoft 365 Security Assessment →

The baselines are published for anyone to use, and using them creates no relationship with CISA. A matching configuration is not compliance, and closing findings is not an assurance outcome.