A practical first pass across identity, privileged access, collaboration, data protection and incident readiness

ThatLazyAdmin | September 2026

If an identity was compromised today, what could an attacker actually do with it

Start by understanding the tenant

Getting access to a new Microsoft 365 tenant is always interesting. Sometimes I open Microsoft Entra and find a well-designed environment. Conditional Access is structured, privileged roles are controlled through Privileged Identity Management, authentication methods make sense, devices are managed and somebody has clearly thought about security architecture.

Other times, I find twelve Global Administrators, Security Defaults disabled, three Conditional Access policies nobody wants to touch, SMS MFA everywhere, guest accounts from 2019 and an enterprise application called something like TestApp2 with permissions nobody can explain.

That is why I do not start by changing settings. I start by understanding what is already there.

A Microsoft 365 tenant is an interconnected security environment. Microsoft Entra ID, Exchange Online, SharePoint, Teams, Intune, Microsoft Defender and Microsoft Purview do not operate in isolation. A weak control in one area can create an attack path into another.

If an identity was compromised today, what could an attacker actually do with it

That question tells me more than a Microsoft Secure Score percentage on its own. The first assessment is about the attack path, the potential blast radius and whether the organisation could detect and investigate what happened.

The following 20 checks are my first pass. They do not replace a full CIS assessment, a threat model or a security architecture review. They establish where the largest risks are and where the deeper work should begin.

The framework behind the assessment

I do not believe tenant hardening should be based on a personal collection of favourite settings. The assessment needs a defensible baseline.

I normally work from the CIS Microsoft 365 Foundations Benchmark, current Microsoft security guidance, Microsoft Secure Score, Microsoft Zero Trust guidance and, where appropriate, NIST SP 800-207. The organisation’s own regulatory, contractual and operational requirements sit alongside those references.

At the time of writing, the current CIS Microsoft 365 Foundations Benchmark is version 7.0.0, published in June 2026. The release added 22 recommendations and incorporated another 12 that CIS moved from the Microsoft Azure Foundations Benchmark. That matters because Microsoft 365 changes quickly. A review based on a benchmark from several years ago may be assessing a platform that no longer exists in the same form.

I also do not treat every recommendation as something that must be enabled blindly. Licensing matters. Business processes matter. Dependencies and compensating controls matter. The framework establishes the baseline; the architecture determines how the control should be implemented.

How I use the framework

Reference	Role in the assessment
CIS Microsoft 365 Foundations	A secure configuration baseline and an evidence checklist, not a substitute for architecture decisions.
Microsoft guidance and Secure Score	Current product guidance, tenant telemetry and recommended actions across identity, devices, applications and data.
NIST Zero Trust	The architectural principle that identity, device and resource context must be evaluated before access is granted.
Business and regulatory requirements	The controls, retention periods and exceptions the organisation must be able to defend.

Tenant identity and privilege

1 Understand what you have inherited

Before touching Conditional Access, I map the tenant. I want to understand how identities are created, where devices are managed, which services are heavily used, what security products are licensed and whether the organisation is cloud-native or still dependent on Active Directory.

The identity architecture is particularly important. In a cloud-only tenant, Microsoft Entra ID is effectively the identity authority. If identities are synchronised from Active Directory through Microsoft Entra Connect Sync or Cloud Sync, there is another security boundary, another administrative path and another set of dependencies to assess.

Licensing changes the remediation plan. There is little value designing around Privileged Identity Management, Microsoft Entra ID Protection, Microsoft Defender for Office 365, advanced Purview controls or Intune functionality before confirming that the tenant is licensed for those capabilities.

I also record verified domains, user and guest counts, administrative accounts, enterprise applications, device-management state, Exchange Online configuration, SharePoint and OneDrive usage, Teams policies, existing Conditional Access policies, security operations tooling and audit retention.

Identity > Device > Access > Application > Data > Detection

That simple chain gives me a working picture of the environment. Once the flow is clear, weaknesses are much easier to place in context.

2 Identify every administrator

Privileged role assignments are usually where the assessment starts to get interesting. I export the Microsoft Entra role assignments and work through them rather than looking only at Global Administrator.

Privileged Role Administrator, Privileged Authentication Administrator, Conditional Access Administrator, Application Administrator, Cloud Application Administrator, Exchange Administrator, SharePoint Administrator, Intune Administrator, Security Administrator and User Administrator can all provide substantial control over the environment.

For every assignment, I want to know who owns it, why the access is required and whether it needs to be permanent. If nobody can explain the business or operational reason, the role requires attention.

Service accounts need the same scrutiny. An old svc-something account with a highly privileged directory role is not a harmless legacy detail. Applications and automation should receive the least privilege they require and should use workload identities or managed identities where those models fit.

The target state is straightforward: normal accounts for normal work, separate administrative identities where appropriate, least privilege for administrative tasks and as little permanent privilege as possible.

3 Eliminate unnecessary standing privilege

After establishing who has administrative access, I check how that access is assigned. A role that an engineer needs once every few weeks does not need to remain active 24 hours a day.

Microsoft Entra Privileged Identity Management lets an administrator become eligible for a role and activate it when required. The activation can be time-bound and can require phishing-resistant authentication, justification, approval and notification. It also leaves an audit trail.

For sensitive roles, I review eligibility versus active assignment, activation duration, authentication strength, justification, approval, notifications, assignment expiry and access reviews. Where role-assignable groups are used, I assess the membership path and whether PIM for Groups is appropriate.

This is not about making administration difficult. It reduces the period during which a compromised administrative identity already has the keys to the tenant.

Standing privilege is convenient Just in time privilege is safer

4 Validate emergency access

I then confirm that the tenant can still be recovered when normal access fails. Microsoft recommends at least two cloud-only emergency access accounts for redundancy. They should use the tenant’s .onmicrosoft.com domain so they do not depend on federation or a custom-domain identity path.

These identities should be completely separate from normal administration. They need permanent active Global Administrator assignments, phishing-resistant authentication that is different from the normal administrator method, securely stored credentials and designated secure devices. They must also be excluded from Conditional Access controls that could lock them out.

Every sign-in and administrative action involving an emergency account should produce an alert. Use should be exceptional and followed by a review.

I also ask for evidence that the accounts work. Microsoft recommends validation drills at least every 90 days, including a sign-in and a small administrative task. An emergency access account last tested two years ago is not much of an emergency plan.

5 Review real authentication methods

The statement MFA is enabled no longer tells me enough. I want to know which authentication methods are allowed, which methods users have registered and which methods they actually use.

There is a material security difference between SMS and a passkey or FIDO2 security key. I review the Authentication Methods policy for passkeys, FIDO2 security keys, Windows Hello for Business, Microsoft Authenticator, Temporary Access Pass, certificate-based authentication, software OATH tokens, SMS and voice.

For administrators, my target is phishing-resistant authentication. The exact method depends on the environment, but privileged access should not rely on a method that can be easily phished or approved through prompt fatigue. Temporary Access Pass can provide a controlled way to bootstrap passwordless credentials.

Microsoft’s current timeline makes this review urgent. From 1 September 2026, users enabled for SMS or voice are automatically enabled and prompted for passkey registration. Microsoft-provided SMS and voice delivery is scheduled to retire on 1 February 2027 for most users, and on 1 July 2027 for Global Administrators and external users. Organisations that still require telephony must plan for a supported customer-managed provider or move users to stronger methods.

A tenant that still depends heavily on SMS is not necessarily in immediate crisis, but the dependency belongs on a dated migration plan.

Access policy and application trust

6 Assess Conditional Access architecture

I care more about Conditional Access architecture than policy count. I have seen six policies that were easy to understand and forty policies that nobody could explain. I will take the six.

The first question is whether the policy set has structure. Policy names should explain their purpose. Privileged identities should receive stronger protection than ordinary users. Emergency accounts should be excluded correctly. Sensitive resources, authentication strengths, device state, risk and session controls should be handled deliberately.

Then I look for overlap and gaps. Conditional Access evaluates every applicable policy, so an old exception or poorly understood grant control can change the result somewhere an administrator did not expect.

I normally expect a coherent set of controls for general user authentication, privileged identities, legacy authentication, risky users and sign-ins, device trust and sensitive resources. Disabled and Report-only policies also matter because they often reveal unfinished work or abandoned troubleshooting.

Exclude All Admins

An exclusion like that deserves investigation. Exclusions should exist because of a documented technical requirement, with an owner and review date, not because somebody became frustrated during deployment.

7 Confirm legacy authentication is gone

Everybody tells me legacy authentication is disabled. I still check.

Microsoft has retired Basic Authentication for many Exchange Online protocols, but legacy clients and exceptions can still surface through older applications, devices, SMTP scenarios and forgotten service accounts. These paths matter because they can bypass modern authentication controls and cannot satisfy modern MFA requirements.

The sign-in logs normally tell the story. I look for attempts from legacy client applications and work backwards to the dependency. Often the source is ordinary: a printer, scanner, old line-of-business application or service account.

I do not break the dependency without understanding it. I identify the owner, document the use case, modernise or replace it, and then enforce the block.

Conditional Access Report-only mode is valuable here. It shows the likely effect before a security improvement becomes Monday morning’s service desk disaster.

8 Validate Security Defaults or its replacement

This check takes about 30 seconds. If Security Defaults is enabled, I establish whether that baseline is appropriate for the organisation. If it is disabled, I immediately want to know what replaced it.

For an organisation with the required Microsoft Entra licensing, the replacement is normally a properly designed Conditional Access architecture. For a smaller tenant without that licensing, Security Defaults can still provide useful baseline protection.

Security Defaults Disabled

Conditional Access Nothing meaningful configured

That combination means a security baseline was removed without another control taking its place. It is a simple configuration check with a potentially large impact.

9 Treat OAuth applications as identities

Users are not the only identities that can access organisational data. Applications can do it too, sometimes without a person at a keyboard.

I review Enterprise Applications and App Registrations, then map what has been granted access to the tenant. Delegated permissions matter, but application permissions deserve particular attention because they can allow unattended access through Microsoft Graph or another API.

For every material application, I want to know who owns it, why it exists, which delegated and application permissions it holds, whether admin consent was granted, which publisher is behind it and how secrets, certificates or federated credentials are protected. Expired owners, unused applications and long-lived credentials are red flags.

I also review the user consent model. Users should not be able to grant arbitrary third-party applications unrestricted access to organisational data. A configured admin consent workflow provides a controlled route for legitimate requests.

Where Microsoft Defender for Cloud Apps is available, App Governance can add visibility into OAuth application permissions and behaviour. The important point is that an application with powerful Graph permissions can represent as much risk as a privileged user.

10 Govern guest accounts

External collaboration is normal. Permanent unmanaged access is not.

Guest accounts accumulate through Teams, SharePoint, enterprise applications and business-to-business collaboration. Projects end, consultants leave and suppliers stop working with the organisation, while the identities and group memberships remain.

I review guest sign-in activity, group and Team membership, application assignments, administrative roles, invitation settings, cross-tenant access configuration and the resources each guest can reach. Last sign-in helps, but it is not the only decision point because some legitimate guests use a resource infrequently.

Where Microsoft Entra ID Governance is available, recurring Access Reviews let resource owners confirm whether external users still require access. Guest expiration and entitlement-management processes can also reduce manual cleanup.

The objective is not to stop collaboration. It is to stop collaboration from becoming permanent access that nobody owns.

Email and collaboration

11 Stop email leaving quietly

One of the first Exchange Online controls I review is external automatic forwarding. A compromised mailbox with an external forwarding rule can leak information quietly for weeks. The attacker does not need to keep signing in because new mail continues to arrive somewhere else.

My normal baseline is to block external automatic forwarding through the outbound spam policy unless there is a documented business requirement. Any exception should have an owner and a review date.

I also check existing mailbox forwarding settings, transport rules and suspicious Inbox rules. Configuration and investigation overlap here. The policy may be secure today, but I still want to know what was created yesterday and whether an attacker already established persistence.

12 Align SPF DKIM and DMARC with reality

Email authentication is another area where a portal can look healthy while DNS tells a different story. For every domain that sends mail, I check SPF, DKIM and DMARC, but I do not stop at confirming that records exist.

I want to understand the complete sending ecosystem. Microsoft 365 might send user mail while a CRM platform sends customer messages, a ticketing system sends support notifications and a website sends contact-form email. All of those systems form part of the organisation’s mail identity.

SPF should accurately identify authorised senders. DKIM should sign mail for each custom domain where supported. DMARC then evaluates alignment and publishes policy for receivers.

The eventual goal should be meaningful DMARC enforcement, but I do not jump directly to p=reject without discovering and aligning legitimate senders first. That is how production systems get broken.

Discover Align Monitor Enforce

13 Configure Defender for Office 365

A Microsoft Defender for Office 365 licence does not prove that the tenant is protected. I look at how the service has actually been configured.

Microsoft’s Standard and Strict preset security policies provide a useful starting point. Standard is designed for most users. Strict applies more aggressive settings and may be appropriate for high-value or higher-risk identities. Built-in protection is useful, but it is not the same as deliberately assigning those profiles.

I review anti-phishing, user and domain impersonation, spoof intelligence, Safe Links, Safe Attachments, anti-malware, anti-spam, outbound spam, quarantine policies and priority accounts. Exceptions receive the same scrutiny as the primary settings.

Executives, finance staff, administrators and people authorised to make payments are obvious impersonation targets. Stronger controls should follow the actual risk model rather than job title alone.

Buying Defender is not the same as deploying Defender

14 Design SharePoint and OneDrive sharing by context

I do not automatically recommend disabling external sharing. That sounds secure until users move files to personal email or consumer file-sharing services because Microsoft 365 has become unusable.

Instead, I review the sharing architecture. I check tenant-level and site-level sharing, OneDrive sharing, anonymous Anyone links, default link type, link expiry, guest expiration, domain restrictions and the controls applied to sensitive sites.

SharePoint sharing operates at both organisation and site level, with the more restrictive setting taking precedence. OneDrive cannot be more permissive than SharePoint. That hierarchy gives us room to match sharing controls to the sensitivity and purpose of a site.

A general collaboration site and the board’s document repository do not need identical sharing policies. The control should reflect the data and the business process, not a giant tenant-wide off switch.

15 Treat Teams as an external access boundary

Teams needs its own review because collaboration extends beyond the Teams admin centre. Guest access, external access, meetings, applications, SharePoint and Microsoft Entra all intersect.

I check who users can communicate with externally, whether guests are allowed, what guests can do, whether anonymous participants can join meetings, which meeting policies apply and how third-party and custom applications are governed.

External access and guest access are different mechanisms and must be assessed separately. I have seen tenants where SharePoint is controlled carefully while Teams allows collaboration patterns nobody realised were possible.

The important requirement is consistency across Microsoft Entra, Teams and SharePoint. A collaboration path is only as strong as the most permissive control along it.

Device data and incident readiness

16 Include device trust in access decisions

A valid password and approved MFA request tell me something useful about the user. They tell me considerably less about the device being used.

Where Intune and Microsoft Defender for Endpoint are available, I review enrolment restrictions, compliance policies, encryption requirements, Defender integration, device risk, stale device records, controls for personally owned devices and the way Conditional Access consumes those signals.

The questions are practical. Is the device managed and compliant? Is BitLocker enabled? Is the endpoint security sensor healthy? Has Defender assessed the device as high risk? Is the request coming from an organisational device at all?

Conditional Access can combine identity, device, risk and resource context. That is much stronger than accepting password correct + MFA approved as the entire access decision.

This is the Zero Trust model in practical terms: evaluate the context of the request before access is granted, and continue evaluating the session when the platform supports it.

17 Confirm the tenant can support an investigation

Security controls will eventually fail. When they do, logs determine whether the organisation can understand the incident or merely guess.

I review Microsoft Purview Audit, available audit workloads, role access and the retention period the tenant actually receives. Microsoft Purview Audit Standard currently retains applicable audit records for 180 days by default for records generated on or after 17 October 2023. Longer retention depends on licensing and configured retention policies.

Whether 180 days is enough depends on the organisation. It may be adequate for one business and insufficient for a regulated environment or a company with specific forensic obligations.

If we discovered today that an account was compromised several months ago could we reconstruct what happened

That is the standard I care about. I also verify that investigators can access the relevant Exchange, SharePoint, Microsoft Entra and administrative events when they are needed, not simply that a portal says auditing is on.

18 Protect sensitive information after access

Most hardening conversations spend a great deal of time on authentication and surprisingly little on the information the identity is protecting. Strong sign-in controls reduce the chance of compromise, but they do not remove the need to control what happens after access is granted.

I review Microsoft Purview Information Protection, sensitivity labels, encryption, Data Loss Prevention and retention. I want to understand how the organisation identifies sensitive data, which labels users can apply, which protections labels enforce and whether the controls follow documents and email beyond the tenant boundary.

For Data Loss Prevention, I check the locations in scope, the sensitive information types or trainable classifiers used, the actions taken, user notifications, policy tips, incident reporting and whether policies were tested before enforcement. A DLP policy that produces constant noise will be ignored; one that blocks legitimate work without an exception process will be bypassed.

I also look for a sensible relationship between SharePoint site sensitivity, Teams or Microsoft 365 group settings, document labels and Conditional Access. Data classification should influence the control applied to the resource.

The goal is not to label everything. It is to identify the information whose disclosure would matter and apply controls that remain usable enough to survive contact with the business.

19 Validate detection ownership and response

A secure configuration is incomplete if nobody is watching the signals it produces. I check whether Microsoft Defender XDR, Microsoft Entra ID Protection and the Microsoft 365 Defender data sources are generating incidents that somebody owns.

The review covers risky users and risky sign-ins, Defender incidents and alerts, alert notification rules, automated investigation settings, priority accounts and any integration with Microsoft Sentinel or another SIEM. I also confirm that the relevant teams have the roles needed to investigate without handing out unnecessary administrative access.

Then I test the operating model. Who receives an alert after hours? What severity creates a page rather than an email? Who can disable an account, revoke sessions, quarantine a device or remove a malicious OAuth grant? How is the decision recorded?

Unused alerts are configuration theatre. The tenant needs a route from signal to decision, and from decision to containment. If that route exists only in one person’s head, it is not reliable enough.

20 Turn findings into a hardening roadmap

The last check is whether the assessment can be turned into action. A forty-page export of failed settings is not a remediation plan.

I use Microsoft Secure Score as one input because it provides useful tenant telemetry and organises recommended actions across identity, devices, applications and data. I do not treat the percentage as the objective. Secure Score does not understand every business dependency, compensating control or attack path in the environment.

Each finding needs enough context to be implemented safely: the affected service, the risk, the evidence, the desired control, licensing dependencies, user impact, owner, target date, validation method and any accepted exception. I normally prioritise exposed privileged access, weak authentication, legacy protocols, application permissions and uncontrolled data paths before lower-impact configuration hygiene.

Changes should be staged. Use Report-only, audit or simulation modes where the product provides them. Test with representative users and workloads. Confirm monitoring before enforcement. Record the baseline so the organisation can show what changed and why.

The result should be a roadmap that reduces attack paths without turning security work into a sequence of undocumented portal changes.

The point of the first 20 checks

These checks are not the end of a Microsoft 365 security assessment. They are the first pass I use to understand the tenant, find the most dangerous gaps and decide where deeper investigation is justified.

The strongest tenants are rarely the ones with the highest number of policies. They are the ones where privileged access is temporary, authentication methods match the risk, applications are treated as identities, collaboration is governed, data controls reflect sensitivity and security events lead to an owned response.

Hardening also is not a one-time project. New applications are consented, roles are assigned, guests are invited, exceptions are created and Microsoft changes the platform. The assessment therefore needs an owner, a review cycle and evidence that important controls still work.

If an identity was compromised today what could the attacker actually do and would we know

If I can answer that question clearly, the tenant is already in a better position. If I cannot, I know exactly where the next stage of the assessment needs to go.

Selected primary references

• CIS Benchmarks June 2026 Update

• CIS Microsoft 365 Foundations Benchmark

• NIST SP 800-207 Zero Trust Architecture

• Microsoft guidance for emergency access accounts

• Microsoft passkey and SMS voice retirement timeline

• Microsoft Purview audit retention policies

• Microsoft Secure Score improvement actions