Remote SupportWhy Identity Matters More Than the Firewall
Most successful breaches today do not involve a firewall bypass. They involve stolen credentials, session token theft, or consent phishing. If your identity platform is weak, nothing else in your stack compensates.
Entra ID (formerly Azure AD) is the identity brain of Microsoft 365. Done well, it blocks the overwhelming majority of account takeover attempts. Done poorly, it is a flat structure of global admins with no MFA and legacy protocols wide open.
How the pieces fit: four questions
Entra ID is the front door to everything in Microsoft 365 and Azure. It is easier to reason about as four questions asked in order, rather than as a product with a long feature list.
The tenant
One boundary that holds your users, your groups, and every application connected to them. Everything below happens inside it.
Question one
Who is asking?
Not every identity is a person. Most tenants have more non-human identities than staff, and they are the ones nobody reviews.
Users
Staff accounts
Groups
How access is granted at scale
Managed identities
Azure resources authenticating themselves
Service principals
An app's identity in your tenant
App registrations
Apps your business owns
Enterprise applications
Third-party apps consented into the tenant
External identities
Guests and customers, via Entra External ID
Question two
Can they prove it?
Authentication. The protocols are industry standards, which is why one Entra login can open hundreds of unrelated apps.
OAuth 2.0
Delegated access to APIs
OpenID Connect
Sign in, built on OAuth
SAML
The older standard, still everywhere
Passkeys and FIDO2
Phishing resistant, becoming the default
Question three
What may they do?
Authorisation. A role says what the action is. A scope says where it applies. Granting the right role at the wrong scope is the most common mistake we find in an audit.
Entra roles
Control of the tenant itself
Azure RBAC
Control of Azure resources
Owner
Full control, including handing it to others
Contributor
Change things, but not permissions
Reader
Look, do not touch
Scope
Management group, subscription, resource group, resource
Question four
Under what conditions?
The security layer, and the part that earns its licence cost. Correct credentials are not enough on their own.
Conditional Access
Rules on device, location, risk and app
Multi-factor authentication
Enforced by policy, not by hope
Privileged Identity Management
Admin rights on request, with an expiry
Access reviews
Proof that access still belongs to someone
Identity Protection
Risk signals on sign-ins and accounts
The part that catches people out
Guests and apps inherit the same model. An external partner and a service principal both get authenticated, both get authorised, and both should be sitting behind the same conditional access thinking as your staff. They rarely are.
Licensing sets the ceiling
Conditional Access, Privileged Identity Management and Identity Protection each depend on the plan attached to the user, so the design is only as good as the licences behind it.
Licensing Tiers: What You Actually Get
Entra ID Free
Included with any M365 subscription. Basic MFA, 500,000 objects, self-service password change. No Conditional Access, no PIM, no governance.
Entra ID P1 (in Business Premium and E3)
Conditional Access, group-based licensing, self-service password reset with writeback, dynamic groups, hybrid identity. The practical minimum.
Entra ID P2 (in E5 or standalone add-on)
Adds PIM, Identity Protection (risk-based policies), access reviews, entitlement management. Required for mature identity governance.
Entra ID Governance (separate SKU)
Lifecycle workflows, separation of duties, advanced access reviews. For mid-market and enterprise with compliance obligations.
Entra Joined vs Entra Registered: Picking the Right Device State
Both options connect a device to Microsoft Entra ID, but they serve different scenarios. The difference matters because it changes how you can manage the device, what Conditional Access can enforce, and who owns the hardware.
Entra Joined
Corporate-owned
The device is joined to Entra ID as its primary identity. Full Intune management. The fleet you own and control end to end.
Entra Registered
BYOD and personal
The device is registered with Entra ID but not joined. Personal phones, contractor laptops, shared kiosks. Lightweight access without owning the hardware.
Choose Entra Joined when
- You need full device lifecycle control with Intune.
- Conditional Access requires a compliant device for corporate apps.
- The device is corporate-owned and assigned to a staff member.
Choose Entra Registered when
- The device is personally owned (BYOD).
- A contractor or short-term user needs access without device takeover.
- Shared or kiosk devices where local accounts are still in use.
Conditional Access Policies That Matter
Conditional Access is the policy engine that evaluates every sign-in. User, device, location, app, and risk signals combine into an allow, block, or challenge decision. These are the baseline policies every tenant should run.
Require MFA for all users
Exclude only a break-glass account. Covers every app, every sign-in, every time.
Block legacy authentication
POP, IMAP, SMTP AUTH, and older Exchange protocols bypass MFA. Block them outright.
Require compliant or hybrid-joined device for M365 apps
Only devices managed by Intune (or hybrid-joined from AD) can access corporate data.
Block sign-ins from high-risk countries
If your business does not operate there, block it. Reduce the attack surface.
Require MFA for admin roles on every sign-in
No session persistence for privileged accounts. Re-auth every time.
Session controls for unmanaged devices
Browser-only, no download, watermark policy for BYOD access.
Sign-in risk and user risk policies
Entra ID P2. Automatically block or challenge risky sign-ins and compromised users.
Terms of use acceptance
Record that users accepted your acceptable use policy. Reviewed annually.
Privileged Identity Management
Standing admin rights are the single biggest source of blast radius in a breach. PIM converts permanent global admin into time-bound, approval-gated, audited role activation. Eligible users request the role when they need it. It expires automatically.
Eligible vs active assignment
Eligible means the user can activate the role. Active means they hold it right now. Keep most assignments eligible.
Activation requirements
Justification text, MFA challenge, optional approver, ticket number. Logged and reportable.
Maximum activation duration
Usually 1 to 8 hours. Short enough to reduce exposure, long enough to get the work done.
Access reviews
Quarterly review of who is eligible for which role. Revoke anything unused.
Break-glass accounts
Two cloud-only accounts with permanent Global Admin. Excluded from Conditional Access. Long passwords, stored securely.
Role scoping
Assign the least-privilege role. Exchange Administrator, not Global Administrator, if someone only manages mailboxes.
Identity Governance
Governance is the discipline of making sure the right people have the right access for the right reasons, and not a day longer than needed.
- Entitlement management: package access to apps, groups, and SharePoint sites into an access package. Users request access, approvals are automated, access expires.
- Access reviews: managers review direct reports' access quarterly. Revocation is one click.
- Lifecycle workflows: automated joiner, mover, leaver workflows driven by HR attributes.
- Separation of duties: stop one person from holding conflicting roles (finance approval and payment execution).
- Terms of use: acceptance captured per user, per policy version.
External Identities and B2B Collaboration
Guest users are a common blind spot. Contractors, partners, and auditors accumulate in the directory for years after the engagement ends. Governance for external identities is non-negotiable.
- Cross-tenant access settings: control which external organisations can collaborate with yours
- Guest user access reviews every 90 days
- MFA required for guests (they do not bypass your policies)
- Sensitivity labels and DLP apply to content shared externally
- Entitlement management with expiration for all guest access packages
Monitoring, Logs, and Alerts
Sign-in logs
30 days in the portal. Export to Log Analytics or a SIEM for longer retention.
Audit logs
Every directory change. Who made it, when, from where. Critical evidence during incidents.
Risky sign-ins and users
Entra ID P2. Automatic risk scoring. Integrate with Defender XDR or a SIEM.
Alerts to investigate
Impossible travel, legacy auth attempts, admin role changes, OAuth app consent grants, mass mailbox rule creation.
Common Mistakes
Too many Global Admins
Two is enough. Everyone else gets a scoped role. PIM everything.
No break-glass accounts
A locked-out tenant is a business outage. Always have two cloud-only break-glass accounts excluded from Conditional Access.
MFA exemptions that never expire
Temporary exemptions become permanent. Set expiry dates and review monthly.
Legacy authentication left on
Every tenant we audit has legacy auth enabled somewhere. Attackers target it first. Block it globally.
Guest users accumulating forever
Audit quarterly. Remove anyone whose engagement ended.
No sign-in log retention beyond 30 days
Incidents are often discovered months later. Stream logs to Log Analytics or your SIEM.
Harden Your Entra ID Tenant
We assess Conditional Access coverage, admin role exposure, MFA health, and governance gaps. Remediation plan with clear priorities.