Azure Active Directory and Zero Trust - Implementing Cloud Identity Management

In the traditional security model, the network was the boundary - if you were inside, you had access. VPN, firewall, VLAN segmentation. In the cloud, that boundary does not exist. Users log in from home, from coffee shop Wi-Fi, from a phone on the train. Applications run in multiple regions, data flows between subscriptions.

Zero Trust replaces the question “are you on our network?” with “can you prove you are who you claim to be, and do you need this access right now?”. Microsoft Entra ID (formerly Azure Active Directory) is the tool that lets you ask this question on every request.

What is Microsoft Entra ID (Azure Active Directory)

Microsoft Entra ID is a cloud-based identity and access management (IAM) service. Until March 2024, it was known as Azure Active Directory (Azure AD). The rebrand did not change functionality - it is the same product under the Microsoft Entra family umbrella.

Key capabilities:

• User authentication - SSO to SaaS applications, internal applications, and Azure resources
• Conditional Access - context-aware access policies based on location, device, risk level
• Privileged Identity Management (PIM) - just-in-time privileged access management
• External Identities - B2B collaboration with partners without creating separate accounts
• Workload Identities - identities for applications, services, and CI/CD pipelines (managed identity, federated credentials)

For organisations operating in the UK and EU, Entra ID stores identity data in-region (datacenters in the Netherlands and Ireland for EU tenants, with UK South and UK West regions available for Azure resources). This simplifies UK GDPR and Data Protection Act 2018 compliance.

The Zero Trust Model - Three Principles

Zero Trust is not a product you buy. It is a security architecture built on three principles:

1. Verify explicitly

Every access request must be authenticated and authorised based on all available signals:

• User identity (who?)
• Location and IP address (from where?)
• Device state (does it meet compliance policy?)
• Target application (accessing what?)
• Risk context (does this session look normal?)

2. Use least privilege access

Users receive exactly the permissions they need - no more. Permissions are:

• Time-limited (just-in-time rather than standing roles)
• Scope-limited (specific subscription, specific resource group)
• Regularly reviewed (access reviews)

3. Assume breach

Design systems as though an attacker is already inside. This means:

• Microsegmentation (do not trust network traffic even within VNets)
• End-to-end encryption
• Continuous monitoring and automated response to anomalies

Implementing Zero Trust with Entra ID - Step by Step

Step 1: Audit your current identity posture

Before implementing anything, you need to know your starting point.

What to check:

• How many accounts hold the Global Administrator role? (should be 2-3 maximum, never more than 5)
• How many service accounts use passwords instead of managed identity?
• Is MFA enforced for all users, or only for admins?
• How many stale guest accounts (B2B) still have active access?
• Are there accounts with non-expiring passwords?

Tools:

• Microsoft Entra admin center → Identity Governance → Access Reviews
• Microsoft Secure Score (Microsoft 365 admin dashboard)
• az ad user list --filter "accountEnabled eq true" in Azure CLI

For many organisations that migrated to Azure during 2020-2022, the audit reveals dozens of over-permissioned accounts. This is a normal starting state - what matters is fixing it systematically.

Step 2: Enforce MFA for all users

Multi-factor authentication is the absolute minimum for Zero Trust. Without MFA, there is no point implementing additional layers - a single stolen password opens the door.

Recommended configuration:

Since 2024, Microsoft enforces MFA for all administrative roles in Entra ID (security defaults v2). If you have not configured this deliberately - it likely runs in default mode without full control over exceptions.

Step 3: Conditional Access - the heart of Zero Trust

Conditional Access is the decision engine that evaluates signals on every sign-in and makes a decision: allow, require additional verification, or block.

Recommended starter policies (minimum viable Zero Trust):

1. Require MFA for all users, all applications - baseline policy
2. Block legacy authentication - IMAP, POP3, SMTP Basic Auth do not support MFA. Disable them.
3. Require compliant device for sensitive data access - device must be Intune-enrolled and meet policy (disk encryption, current OS, antivirus)
4. Block sign-ins from countries where you do not operate - if your team operates in the UK and EU, block sign-ins from high-risk geographies
5. Require re-authentication for sensitive operations - role changes, password resets, Azure Portal access

{
  "displayName": "Require MFA for all users - all cloud apps",
  "state": "enabled",
  "conditions": {
    "users": { "includeUsers": ["All"] },
    "applications": { "includeApplications": ["All"] },
    "clientAppTypes": ["browser", "mobileAppsAndDesktopClients"]
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": ["mfa"]
  }
}

Evaluation order: Conditional Access policies are evaluated in parallel (not sequentially). If any two policies conflict - the more restrictive one wins. One “Block” policy overrides ten “Allow” policies.

Step 4: Privileged Identity Management (PIM)

PIM eliminates standing administrative roles. Instead of giving someone the “Owner” role on a subscription permanently, you make the assignment eligible - they can activate it on demand, for a limited time, after additional verification.

How it works in practice:

1. A DevOps engineer needs the Contributor role on a production resource group
2. They sign into the Entra portal → Privileged Identity Management → My Roles
3. They click “Activate” next to the Contributor role
4. They provide justification (Jira ticket, problem description)
5. They complete additional MFA
6. The role activates for 4 hours (configurable)
7. After 4 hours - automatic deactivation

Recommended PIM configuration:

PIM requires a Microsoft Entra ID P2 licence (or Microsoft Entra ID Governance). Cost: ~$9/user/month. For a 50-200 person organisation, that is $450-$1800/month - modest compared to the cost of a security incident.

Financial services teams in Leeds and Manchester - where regulatory scrutiny from the FCA and PRA is intense - find PIM particularly valuable for demonstrating that privileged access is time-boxed and auditable.

Step 5: Workload Identity - identities for applications and pipelines

People are not the only identities in an organisation. Applications, CI/CD pipelines, automation scripts - all need access to Azure resources. Zero Trust requires that these identities are managed too.

Preference hierarchy (most secure first):

1. Managed Identity (system-assigned) - Azure creates and manages the identity automatically. No password, no certificate to rotate. Best option for resources running in Azure (App Service, AKS pods, Azure Functions).

2. Managed Identity (user-assigned) - same as above, but shared across resources. Use when multiple resources need the same access.

3. Workload Identity Federation (federated credentials) - for resources outside Azure (GitHub Actions, GitLab CI, AWS). Eliminates secrets via OIDC. The pipeline exchanges its token for an Entra ID token without transmitting a password.

4. Service Principal with certificate - when federation is not possible. Certificate rotated every 6-12 months.

5. Service Principal with password (client secret) - last resort. Secret stored in Key Vault, rotated every 90 days. Avoid if possible.

For CI/CD pipelines on GitHub Actions, workload identity federation is the standard approach. We covered the detailed setup in our AKS Workload Identity Federation runbook.

Monitoring and Incident Response

Zero Trust without monitoring is fiction. You need visibility into what is happening and automated response to anomalies.

Microsoft Entra ID Protection

An ML engine that analyses sign-ins and assigns risk levels:

• Low risk - sign-in from a new device, but known location
• Medium risk - sign-in from a different country than usual (impossible travel)
• High risk - sign-in from anonymous IP, credentials found in known breach (leaked credentials)

Integration with Conditional Access: You can create a policy “if session risk = high → force password reset and MFA”. Response is automatic - you do not wait for SOC to analyse the alert manually.

Audit Logs and Sign-in Logs

Entra ID generates two types of logs:

• Sign-in logs - every sign-in (success and failure), including IP, device, application, Conditional Access result
• Audit logs - every configuration change (user added, role changed, policy modified)

Recommendation: Export logs to an Azure Log Analytics Workspace (retention is 90 days in Entra, but configurable up to 2 years in Log Analytics). For audit and regulatory requirements, 2 years is a safe minimum.

Alert rules (minimum)

Configure alerts for:

• Global Administrator role activation
• More than 5 failed sign-ins from one IP within 10 minutes
• Sign-in from a country not on the allowed list
• New federation added to the tenant (critical - tenant-level attack vector)
• Conditional Access policy deletion

Cost of Implementing Zero Trust on Entra ID

What you get at each tier:

• Free/P1: SSO, MFA, Conditional Access (basic), Application Proxy
• P2: + PIM (Privileged Identity Management), Identity Protection (risk-based CA), Access Reviews
• Governance: + Lifecycle Workflows, Entitlement Management, automated onboarding/offboarding

For a 100-person organisation already on M365 E3 (which includes P1):

• Conditional Access + MFA = $0 additional cost (already paid for)
• Upgrade to P2 (PIM + Identity Protection) = ~$900/month ($9 × 100 users)

Implementation cost (consulting + configuration) for 50-200 person organisations: typically 3-5 days of engineering work.

Common Implementation Mistakes

1. No break-glass accounts - if the only Global Admin loses their password or FIDO2 key, who unlocks the tenant? Always maintain 2 emergency access accounts excluded from Conditional Access, with strong passwords stored in a physical safe.

2. Overly aggressive Conditional Access without testing - enabling “block all countries except UK” without checking whether your German partner can still sign in. Use “Report-only” mode for 2-4 weeks before switching to “Enabled”.

3. Ignoring service accounts - a CI/CD pipeline with a client secret that has not been rotated in 18 months. Service accounts should NOT be excluded from MFA and Conditional Access - they should use managed identity.

4. Security defaults + Conditional Access simultaneously - these are mutually exclusive. If you create Conditional Access policies, disable security defaults. Otherwise, behaviour is unpredictable.

5. No communication plan - deploying MFA without informing staff generates a wave of support tickets and frustration. Prepare step-by-step instructions, a Q&A session, and give a week to register MFA methods before enforcement.

How We Can Help

At Devopsity, we implement Zero Trust on Entra ID for organisations in financial services, e-commerce, and SaaS. A typical engagement includes:

• Audit of current identity posture and permissions (1 day)
• Design of Conditional Access and PIM policies (1-2 days)
• Implementation and testing in report-only mode (1-2 days)
• Switch to production mode + team training (1 day)

If your organisation is on M365 E3 or E5 but Conditional Access still runs in default mode - you are likely paying for licences you are not using fully.

Need an identity audit on Azure?

Book a free 30-minute call. No pitch - a technical conversation about your environment.

Book a call

Frequently Asked Questions

Is Azure Active Directory the same as Microsoft Entra ID?

Yes. Microsoft rebranded it in 2023 (completed in 2024). All functionality remains identical. If your internal documentation mentions “Azure AD” - it is the same product, now called Entra ID.

Does Zero Trust require replacing all existing infrastructure?

No. Zero Trust is an iterative model. You start with MFA and Conditional Access (one week of work), then add PIM (another week), then workload identities (as you modernise applications). Each step provides an immediate security improvement.

How much does Zero Trust implementation cost for a 100-person company?

If you have M365 E3 - Conditional Access and MFA are free (already paid for in the licence). Upgrade to P2 (PIM + Identity Protection) costs ~$900/month. Consulting for implementation: 3-5 days of work. Total first-year cost: ~$12,000-15,000 (licences + consulting).

Does Conditional Access work for on-premise applications?

Yes, through Application Proxy or Azure AD Connect with Hybrid Azure AD Join. On-premises applications can use the same Conditional Access policies as cloud applications. This requires deploying an Application Proxy connector on a server in your local network.

How long does implementation take?

Minimum viable Zero Trust (MFA + basic Conditional Access) - 1-2 weeks. Full implementation with PIM, Identity Protection, and workload identities - 4-6 weeks. The most time-consuming part is migrating service accounts from passwords to managed identity.