# azureblog.co.uk: full text of every post > Plain-text copies of every post on https://azureblog.co.uk, newest first. Each post links to Microsoft's own documentation. Structured data is at https://azureblog.co.uk/open/v1/index.json. --- # Azure Arc for servers: the complete setup guide, and why it changes how you run everything outside Azure URL: https://azureblog.co.uk/posts/azure-arc-servers-complete-setup/ Published: 2026-10-17 Tags: Azure, Security, Governance > One agent turns any Windows or Linux server, in your datacentre, a branch office or another cloud, into an Azure resource you can patch, protect, monitor and govern from one place. How it works, how to plan it, every onboarding method, what to switch on, day-two operations and troubleshooting, plus a planner that builds your firewall list and onboarding script. Most estates don't live in one place. There's a datacentre, a couple of branch offices, some workloads in another cloud, and usually one server under a desk that nobody quite owns. Each one tends to come with its own patching, its own monitoring and its own blind spots. Azure Arc-enabled servers fixes that without moving anything. You install one agent and the server becomes an Azure resource. It gets a resource ID, sits in a resource group, takes tags, and can be managed by the same Azure tools you already use for your Azure VMs. This guide goes end to end: how Arc works under the hood, how to plan a rollout, the network options, every onboarding method, what to switch on afterwards, how to lock it down, how to run it day to day, and how to fix it when it breaks. Everything comes from Microsoft's own documentation, linked at the end. ## What Arc is, and what it isn't Microsoft's definition: Arc-enabled servers lets you manage Windows and Linux physical servers and virtual machines hosted outside of Azure, on your corporate network or with another cloud provider. - It doesn't migrate anything. The server stays where it is and keeps running its workload. Arc adds a management connection. - It's not for Azure VMs. The agent won't install on an Azure VM, and the installer rolls back if it detects one. - An Arc outage doesn't stop your servers. Microsoft is explicit that an outage only affects management through Arc, not the workload itself. - There's no limit on the number of Arc-enabled servers or extensions in a resource group or subscription. - Your data stays in region. By default, customer data stays in the region you register the server in. The metadata Arc collects is things like the OS name and version, computer name, FQDN and agent version. ## How it works ### The agent The Azure Connected Machine agent is a handful of services working side by side: | | Service (Windows name) | What it does | Runs as | Hybrid Instance Metadata Service (himds) | Holds the connection to Azure, syncs metadata and hosts the local endpoint that hands out managed identity tokens | Unprivileged virtual account (NT SERVICE\himds), or the himds user on Linux | Machine configuration (GCArcService) | Audits and enforces machine configuration policies | Local System, or root on Linux | Extension manager (ExtensionService) | Installs, updates and removes VM extensions | Local System, or root on Linux | Azure Arc Proxy | Routes the agent's traffic. Used with Azure Arc gateway | Network Service, or the arcproxy user on Linux On Windows it installs to %ProgramFiles%\AzureConnectedMachineAgent, with configuration, logs and identity files in %ProgramData%\AzureConnectedMachineAgent. On Linux it lives under /opt/azcmagent/ and /var/opt/azcmagent/. ### The connection Every connection the agent makes is outbound HTTPS on TCP 443. There are no inbound ports to open and no VPN to build. The agent keeps a persistent connection open for notifications and sends a heartbeat every five minutes. | | Status | What it means | Connected | Heartbeats are arriving. Everything works. | Disconnected | No heartbeat for 15 to 30 minutes. The server is off, the agent isn't running, or the network path is blocked. | Expired | Disconnected for 45 days. It can't be managed through Arc until an admin disconnects and reconnects it. The server's identity credential is valid for up to 90 days and renews every 45, which is why a long disconnection matters. If a server is disconnected, its machine configuration assignments are kept locally for 14 days and then deleted. ### The control model The only way to make the agent do anything, such as install an extension or run a command, is through the server's resource in Azure. So Azure RBAC on that resource is your access control, and Azure activity logs are your audit trail. On top of that, local settings on the server take precedence over anything set in the cloud, which we'll use later to lock it down. ## Plan before you onboard ### Organise your resources An Arc server is a normal Azure resource, so the structure you choose now drives RBAC, Azure Policy and cost reporting later. A few patterns that work well: - Resource groups per site or environment, such as rg-arc-london-prod. That's your natural boundary for who can manage what. - Tags at connect time, such as Datacenter, Environment and Owner. azcmagent connect takes a --tags flag, so every server arrives labelled. - The nearest region when you generate the script. Microsoft recommends the Azure region closest to the server, and it's also where that server's data is kept. ### Who needs which role | | Who | Role | Scope | Whoever, or whatever, connects servers | Azure Connected Machine Onboarding (or Contributor) | Target resource group | Day-to-day server admins | Azure Connected Machine Resource Administrator | Resource group | Anyone using the portal's script generator | Reader, in addition | Resource group | Whoever creates the onboarding service principal | Owner or User Access Administrator, plus Application Administrator or Cloud Application Administrator if users can't register apps | Subscription | Associating servers with Private Link | Microsoft.HybridCompute/privateLinkScopes/read | The Private Link Scope ### Choose a network pattern | | Pattern | Good for | Watch out for | Direct internet | Simple sites with open outbound HTTPS | About a dozen endpoints to allow, including the regional Entra endpoint | HTTP proxy | Most enterprises | Don't break and inspect the traffic. A Log Analytics gateway isn't supported as the agent's proxy | Azure Arc gateway | Locked-down proxies where every URL is a change request | Cuts the list to seven endpoints. Public cloud only, no proxy bypass, avoid TLS inspection on the gateway URL | Private Link | Traffic over ExpressRoute or VPN | Only the Arc endpoints go private. Entra ID and Resource Manager still need a public route unless you add more private links ## The network in detail ### Endpoints and service tags The planner below builds the exact list for your options. The short version: - Always: login.microsoftonline.com, *.login.microsoft.com, pas.windows.net, *.his.arc.azure.com, *.guestconfiguration.azure.com, the guest notification service and *.servicebus.windows.net. - When installing: download.microsoft.com for Windows and packages.microsoft.com for Linux. - When connecting or disconnecting: management.azure.com. - Service tags, if your firewall supports them: AzureActiveDirectory, AzureTrafficManager, AzureResourceManager, AzureArcInfrastructure, Storage and AzureFrontDoor.Frontend. Allow the whole AzureArcInfrastructure tag, not a regional slice. One that catches people out: the agent normally gets tokens from a regional Entra endpoint, such as uksouth.login.microsoft.com, and only falls back to the global one. Allowing login.microsoftonline.com on its own isn't enough. Servers need TLS 1.2 or 1.3, which is on by default from Windows Server 2012 R2. ### Using a proxy Set the proxy on the agent itself rather than through environment variables. No service restart is needed: ``` azcmagent config set proxy.url "http://proxy.contoso.com:8080" azcmagent config get proxy.url azcmagent config clear proxy.url ``` If some traffic should skip the proxy, for example because Entra ID is reachable directly, use proxy.bypass with one or more of AAD, ARM, AMA, Arc and ArcData: ``` azcmagent config set proxy.bypass "AAD,ARM" ``` Some extensions don't inherit the agent's proxy settings, so check each extension's documentation. ### Azure Arc gateway The gateway is an Azure resource that acts as a single front door for Arc traffic. With it, servers only need seven endpoints: your gateway URL (.gw.arc.azure.com), management.azure.com, login.microsoftonline.com plus your regional login endpoint, gbl.his.arc.azure.com, .his.arc.azure.com, and the package download site for your OS. - Up to five gateways per subscription. For servers only, one gateway handles around 2,000 servers per region. - The onboarding script gains a --gateway-id parameter. From agent 1.51, existing servers switch to the gateway automatically when you associate them. - Some extensions still need their own endpoints. The Azure Monitor Agent, for example, needs your Log Analytics workspace's ingestion endpoint. ### Private Link Create an Azure Arc Private Link Scope and a private endpoint, then connect servers with --private-link-scope "". Only *.his.arc.azure.com and *.guestconfiguration.azure.com go through the private endpoint. Entra ID and the notification service stay public, and management.azure.com stays public unless you also set up a Resource Manager private link. ## Plan your rollout with the planner Pick your options below. You'll get the exact firewall allow-list, an onboarding script with your values filled in, and a readiness checklist. Nothing you type leaves your browser. [Interactive tool: open the post on azureblog.co.uk to use it.] ## Before you start: prerequisites ### Supported operating systems - Windows Server 2012, 2012 R2, 2016, 2019, 2022 and 2025, Desktop or Server Core, x64 only. - Windows 10 and 11, but only when used like a server: always on, always connected. - Linux, including Ubuntu 18.04 to 24.04, RHEL 7 to 10, Debian 11 to 13, SLES 12 SP5 and 15, Rocky, Alma, Oracle Linux, Azure Linux and Amazon Linux. 64-bit only. If a version isn't on Microsoft's list, it isn't supported. Linux needs systemd, wget and openssl, plus gnupg on Debian-based systems. On Windows, if Group Policy controls the "Log on as a service" right, add NT SERVICE\himds to it. ### Resource providers ``` az account set --subscription "" az provider register --namespace Microsoft.HybridCompute az provider register --namespace Microsoft.GuestConfiguration az provider register --namespace Microsoft.HybridConnectivity az provider register --namespace Microsoft.AzureArcData # only for Arc-enabled SQL Server az provider register --namespace Microsoft.Compute # for Update Manager ``` ## Step by step: your first server - Register the resource providers above, once per subscription. - Create the resource group, following the structure you planned. - Open the network using the planner's list, a proxy, Arc gateway or Private Link. - Generate the script. In the portal, go to Azure Arc > Machines > Onboard/Create > Onboard existing machines. Pick the subscription, resource group and nearest region, add tags, and download the script. - Check the network from the server before connecting: ``` azcmagent check --location uksouth ``` - Run the script as an administrator. On Windows it must be a 64-bit PowerShell session. Without a service principal it signs you in through a browser or device code. - Confirm it worked. The server should show as Connected under Azure Arc > Machines within a few minutes, and azcmagent show on the server should say the same. ## Onboarding at scale ### The service principal For anything beyond a handful of servers, use a service principal. In the portal, go to Azure Arc > Service principals > Add, scope it to the resource group or subscription, choose a secret lifetime, and give it the Azure Connected Machine Onboarding role. Microsoft describes it as a limited identity with only the permission needed to connect machines, and it's used only during onboarding. When you generate the script, choose Authenticate machines automatically and pick the service principal. The connect command then looks like this: ``` azcmagent connect ` --subscription-id "" ` --resource-group "rg-arc-london-prod" ` --location "uksouth" ` --tenant-id "" ` --service-principal-id "" ` --service-principal-secret "" ` --tags "Datacenter=London,Environment=Prod" ``` Microsoft recommends passing the secret through a configuration file rather than on the command line, so it doesn't end up in console logs. Keep the secret's lifetime short and remove it when the rollout's done. ### Every way to roll it out | | Method | OS | Best for | Portal-generated script | Windows, Linux | One server or a handful | PowerShell | Windows, Linux | Scripted rollouts | Service principal script | Windows, Linux | Any tool that can run a script unattended | Group Policy | Windows | Domain-joined servers | Configuration Manager (scripts or task sequence) | Windows | Estates already managed by ConfigMgr | Ansible | Windows, Linux | Linux-heavy estates and Ansible shops | Multicloud connector (AWS) | Windows, Linux | EC2 instances, discovered automatically | Arc-enabled VMware vSphere | Windows, Linux | VMware estates, through vCenter (VMware Tools required) | Windows Admin Center | Windows | Servers you already manage in WAC | Azure Arc setup for Windows Server | Windows | Interactive setup on the server itself ### Group Policy, step by step - Create a share that domain controllers and servers can reach. Give domain computers Change permission and domain admins Full Control. - Download Microsoft's ArcEnabledServersGroupPolicy release from GitHub and the agent MSI from aka.ms/AzureConnectedMachineAgent, and put both on the share. - On a domain controller, run DeployGPO.ps1: ``` .\DeployGPO.ps1 -DomainFQDN contoso.com -ReportServerFQDN Server.contoso.com ` -ArcRemoteShare AzureArcOnBoard -ServicePrincipalSecret $ServicePrincipalSecret ` -ServicePrincipalClientId $ServicePrincipalClientId -SubscriptionId $SubscriptionId ` -ResourceGroup $ResourceGroup -Location $Location -TenantId $TenantId ``` - Link the new GPO, [MSFT] Azure Arc Servers (datetime), to the OU of servers you want to onboard. It runs a scheduled task on each one. Scope it carefully, because everything in scope gets onboarded. - Once the servers show as Connected, disable the GPO, so the task doesn't run again at every reboot or policy refresh. ### Things to decide during rollout - SQL Server: servers running SQL Server have their SQL instances connected to Arc automatically. To opt out, add the tag ArcSQLServerExtensionDeployment = Disabled when you connect. - Automatic agent upgrades (preview, agent 1.57+, public cloud only): add --enable-automatic-upgrade to the connect command, or assign the built-in policy Configure Azure Arc-enabled Servers to enable automatic upgrades. ## After onboarding: switch things on This is where Arc pays off. Use Azure Policy at the resource group or management group so every new server picks everything up the moment it connects. ### Update Manager Assign the built-in policy Configure periodic checking for missing system updates on Azure Arc-enabled servers, once for Windows and once for Linux, with a remediation task. Update Manager then checks each server for missing updates every 24 hours. Add a maintenance configuration to patch on a schedule alongside your Azure VMs. ### Azure Monitor Create a data collection rule for the logs and counters you want, then assign Microsoft's built-in initiative to configure Windows or Linux Arc machines with the Azure Monitor Agent, passing the DCR's resource ID. The policy installs the agent and associates the rule on every server it covers. ### Defender for Cloud Turn on Defender for Servers for the subscription. Arc servers in it get Microsoft Defender for Endpoint, vulnerability management and threat detection, just like Azure VMs. Plan 2 also covers Update Manager and machine configuration costs for those servers. ### Machine configuration Assign machine configuration policies, such as Microsoft's security baselines, to audit settings inside every server, wherever it runs. ### Windows Server Management enabled by Azure Arc If your Windows Server licences have active Software Assurance or are subscription licences, you can unlock a set of services at no extra cost beyond networking, storage and log ingestion: - Update Manager, Change Tracking and Inventory, and machine configuration (Windows Server 2012 and later). - Windows Admin Center in Azure, Remote Support, Best Practices Assessment, Azure Site Recovery configuration, and discounted Azure File Sync (Windows Server 2016 and later). - Network HUD (Windows Server 2025). It isn't automatic. You have to attest: go to Azure Arc > Licenses > Azure Benefits - Windows Server, select the servers, choose Activate benefits, accept the terms and select Activate. The status changes to Activated within about ten minutes. Servers need agent 1.47 or later and must be Connected. ### Managed identity: no more secrets in config files Every Arc server gets a system-assigned managed identity. Grant it access to, say, a Key Vault, and apps on the server can get a token from a local endpoint at http://localhost:40342. Only members of the local Administrators or Hybrid Agent Extension Applications group on Windows, or the himds group on Linux, can request tokens. The request is a two-step challenge that proves the caller can read a protected local file: ``` $apiVersion = "2020-06-01" $resource = "https://vault.azure.net" $endpoint = "{0}?resource={1}&api-version={2}" -f $env:IDENTITY_ENDPOINT, $resource, $apiVersion try { Invoke-WebRequest -Method GET -Uri $endpoint -Headers @{ Metadata = 'True' } -UseBasicParsing } catch { $secretFile = ($_.Exception.Response.Headers["WWW-Authenticate"] -split "Basic realm=")[1] } $secret = Get-Content -Raw $secretFile $response = Invoke-WebRequest -Method GET -Uri $endpoint -Headers @{ Metadata = 'True'; Authorization = "Basic $secret" } -UseBasicParsing $token = (ConvertFrom-Json $response.Content).access_token ``` ## Lock the agent down For sensitive servers, use the agent's local controls. They take precedence over anything set in the cloud: ``` # only allow the extensions you actually use azcmagent config set extensions.allowlist "Microsoft.Azure.Monitor/AzureMonitorWindowsAgent,Microsoft.Azure.AzureDefenderForServers/MDE.Windows" # turn off remote access features azcmagent config set incomingconnections.enabled false # only if you don't use machine configuration on this server azcmagent config set guestconfiguration.enabled false ``` Beyond that, keep RBAC tight. Anyone who can write to an Arc server resource can install extensions and run commands on the machine, so treat Azure Connected Machine Resource Administrator on your Tier 0 servers like any other privileged role, ideally through PIM. ## Day-two operations ### Keeping the agent up to date - Windows: Microsoft recommends Microsoft Update. On domain-joined servers, enable "Install updates for other Microsoft products" in the Configure Automatic Updates policy. Or upgrade silently with msiexec.exe /i AzureConnectedMachineAgent.msi /qn. - Linux: upgrade through your package manager (apt, yum or zypper) from packages.microsoft.com. - Either: Update Manager can upgrade the agent, or turn on automatic agent upgrade. ### Watching the estate with Resource Graph Arc servers are queryable in Azure Resource Graph like everything else. A quick health view: ``` Resources | where type == 'microsoft.hybridcompute/machines' | summarize Servers = count() by Status = tostring(properties.status) ``` And Microsoft's sample for servers running an outdated agent: ``` AdvisorResources | where type == 'microsoft.advisor/recommendations' | where properties.category == 'HighAvailability' | where properties.shortDescription.solution == 'Upgrade to the latest version of the Azure Connected Machine agent' | project id, JoinId = toupper(properties.resourceMetadata.resourceId), machineName = tostring(properties.impactedValue), agentVersion = tostring(properties.extendedProperties.installedVersion), expectedVersion = tostring(properties.extendedProperties.latestVersion) | join kind=leftouter ( Resources | where type == 'microsoft.hybridcompute/machines' | project machineId = toupper(id), status = tostring(properties.status) ) on $left.JoinId == $right.machineId | where status != 'Expired' | summarize by id, machineName, agentVersion, expectedVersion | order by tolower(machineName) asc ``` Turn the first query into an alert and you'll know about disconnected servers before anyone asks. ### Decommissioning a server Do it in this order, because uninstalling the agent doesn't remove extensions or the Azure resource: - Remove all extensions from the server in Azure. - Disconnect: run azcmagent disconnect as an administrator. This deletes the Azure resource and clears the agent's local state. - Uninstall the agent: through Programs and Features or msiexec /x on Windows, or your package manager on Linux. If the Azure resource has already been deleted, use azcmagent disconnect --force-local-only to clean up the server. ## What it costs [Diagram: From Microsoft's Azure Arc pricing page.] Two ways to bring the bill down: - Windows Server Software Assurance or subscription licences, through the attestation above. - Defender for Servers Plan 2, which includes Update Manager and machine configuration for the servers it covers. Update Manager on Arc is charged per server, prorated daily, and only for days the server is Connected and actually managed by Update Manager. ## Troubleshooting ### Start here - azcmagent check --location tests every endpoint the agent needs. Run it first, always. - azcmagent show shows the agent's status and connection details, including the proxy settings it's using. - Add --verbose to any command, then read the log: %ProgramData%\AzureConnectedMachineAgent\Log\azcmagent.log on Windows or /var/opt/azcmagent/log/azcmagent.log on Linux. - azcmagent logs collects everything into a zip for a support case. ### Common error codes | | Code | What it means | Fix | AZCM0018 | Not run as administrator or root | Rerun in an elevated session | AZCM0026 | Network problem, or a required service is unavailable | Run azcmagent check. With Private Link, pass --private-link-scope | AZCM0041 | Invalid credentials | Check the service principal ID, secret, expiry and tenant | AZCM0042 | Couldn't create the Azure resource | Check the onboarding role on the resource group | AZCM0044 | A resource with the same name already exists | Use --resource-name or delete the old resource | AZCM0062 | Error while connecting | Read the message. If the resource was created, delete it before retrying | AZCM0064 | Agent service not responding | Run elevated and restart the himds service | AZCM0067 | Already connected | Run azcmagent disconnect first | AZCM0068 | Couldn't look up the subscription by name | Use the subscription GUID ### Usual suspects - Only the global login endpoint is allowed. Add the regional one, such as uksouth.login.microsoft.com. - TLS inspection on the proxy. Exclude the Arc endpoints. - A Log Analytics gateway used as the proxy. It isn't supported for the Connected Machine agent. ## FAQ **Does Arc move my servers into Azure?** No. The server stays where it is. Arc creates a resource in Azure that represents it, so you can manage it with Azure tools. **What happens to my servers if Azure Arc has an outage?** Your workloads keep running. Only management through Arc is affected until the service recovers. **Can I put the agent on an Azure VM to try it out?** No. Azure VMs are already Azure resources, and the installer rolls back if it detects Azure. Use a server or VM outside Azure. **Do I need a VPN or ExpressRoute?** No. The agent only makes outbound HTTPS connections. If you want traffic off the public internet, use Private Link, but note that some endpoints still need a public route. **Is there a limit on how many servers I can connect?** Not per resource group or subscription. The only per-resource-group limit is 800 for Private Link Scope resources, and Arc gateway has its own sizing guidance. **Can I rename an Arc server or move it to another region?** Not in place, because Azure resource names can't change. Note and remove its extensions, run azcmagent disconnect, then connect again with --resource-name or a new --location and redeploy the extensions. The agent stays installed throughout. Sources - Microsoft Learn: What is Azure Arc-enabled servers? (https://learn.microsoft.com/azure/azure-arc/servers/overview) - Microsoft Learn: Azure Connected Machine agent overview (https://learn.microsoft.com/azure/azure-arc/servers/agent-overview) - Microsoft Learn: Connected Machine agent prerequisites (https://learn.microsoft.com/azure/azure-arc/servers/prerequisites) - Microsoft Learn: Network requirements (https://learn.microsoft.com/azure/azure-arc/servers/network-requirements) - Microsoft Learn: Manage proxy settings (https://learn.microsoft.com/azure/azure-arc/servers/manage-agent-proxy-settings) - Microsoft Learn: Azure Arc gateway (https://learn.microsoft.com/azure/azure-arc/servers/arc-gateway) - Microsoft Learn: Private Link for Azure Arc (https://learn.microsoft.com/azure/azure-arc/servers/private-link-security) - Microsoft Learn: Deployment options (https://learn.microsoft.com/azure/azure-arc/servers/deployment-options) - Microsoft Learn: Onboard at scale with a service principal (https://learn.microsoft.com/azure/azure-arc/servers/onboard-service-principal) - Microsoft Learn: Onboard with Group Policy (https://learn.microsoft.com/azure/azure-arc/servers/onboard-group-policy-powershell) - Microsoft Learn: azcmagent connect (https://learn.microsoft.com/azure/azure-arc/servers/azcmagent-connect) - Microsoft Learn: Manage the Connected Machine agent (https://learn.microsoft.com/azure/azure-arc/servers/manage-agent) - Microsoft Learn: Rename or move an Arc-enabled server (https://learn.microsoft.com/azure/azure-arc/servers/manage-howto-migrate) - Microsoft Learn: Uninstall the agent (https://learn.microsoft.com/azure/azure-arc/servers/uninstall-agent) - Microsoft Learn: Security overview (https://learn.microsoft.com/azure/azure-arc/servers/security-overview) - Microsoft Learn: Managed identity authentication (https://learn.microsoft.com/azure/azure-arc/servers/managed-identity-authentication) - Microsoft Learn: Windows Server Management enabled by Azure Arc (https://learn.microsoft.com/azure/azure-arc/servers/windows-server-management-overview) - Microsoft Learn: Deploy Azure Monitor Agent with Azure Policy (https://learn.microsoft.com/azure/azure-arc/servers/deploy-ama-policy) - Microsoft Learn: Periodic assessment at scale (https://learn.microsoft.com/azure/update-manager/periodic-assessment-at-scale) - Microsoft Learn: Update Manager FAQ (https://learn.microsoft.com/azure/update-manager/update-manager-faq) - Microsoft Learn: Resource Graph samples for Arc-enabled servers (https://learn.microsoft.com/azure/azure-arc/servers/resource-graph-samples) - Microsoft Learn: Troubleshoot agent connection issues (https://learn.microsoft.com/azure/azure-arc/servers/troubleshoot-agent-onboard) - Azure Arc pricing (https://azure.microsoft.com/pricing/details/azure-arc/core-control-plane/) --- # Every Entra default user permission, what it does, and how to check yours in one command URL: https://azureblog.co.uk/posts/entra-default-user-permissions-review/ Published: 2026-10-16 Tags: Entra ID, Security, Governance > The agent blueprints toggle is the newest switch under Default user role permissions, but it isn't the only one. Here's what each setting controls, its Graph name, and a short PowerShell check to see where your tenant stands. This week's change to agent blueprints (https://azureblog.co.uk/posts/users-can-create-agent-blueprints/) sent a lot of people to Entra ID > Users > User settings for the first time in a while. While you're there, it's worth checking the rest of the page. Each toggle decides what every ordinary user in your tenant can do without an admin role. ## The settings Most of these map to properties on the defaultUserRolePermissions object in Microsoft Graph, so you can read them all at once. - Users can register applications (allowedToCreateApps). Lets any user create app registrations. If you turn it off, give the Application Developer role to people who need it. - Users can create agent blueprints. The new one, rolling out from November. Controls whether default users can create the templates AI agents are built from. Separate from the app registration setting. - Restrict non-admin users from creating tenants (allowedToCreateTenants). Note the inversion: Yes in the portal means the Graph value is false. Users with the Tenant Creator role can still create tenants either way. - Users can create security groups (allowedToCreateSecurityGroups). Also controlled from the Groups settings page. - User consent to apps (permissionGrantPoliciesAssigned). Which app consent policy applies when users grant apps access to their data. An empty list means user consent is turned off. This one lives under Enterprise apps > Consent and permissions. - Read own BitLocker keys (allowedToReadBitlockerKeysForOwnedDevice). Whether device owners can see their own recovery keys. - Read other users (allowedToReadOtherUsers). Microsoft's documentation is blunt: do not set this to false. It breaks normal directory lookups. ## Check your tenant in one go ``` Connect-MgGraph -Scopes Policy.Read.All (Get-MgPolicyAuthorizationPolicy).DefaultUserRolePermissions | Format-List ``` Look for AllowedToCreateApps, AllowedToCreateTenants, AllowedToCreateSecurityGroups and an empty or populated PermissionGrantPoliciesAssigned. That's the whole picture in a few lines, and it's easy to drop into a scheduled check. To change one, you need the Policy.ReadWrite.Authorization permission and at least the Privileged Role Administrator role. For example, to stop users registering apps: ``` Connect-MgGraph -Scopes Policy.ReadWrite.Authorization Update-MgPolicyAuthorizationPolicy -DefaultUserRolePermissions @{ AllowedToCreateApps = $false } ``` Microsoft hasn't yet documented a Graph property for the agent blueprints setting, so set that one in the admin centre for now. ## A sensible starting point [Diagram: A common baseline. Adjust to how your organisation works.] For consent, the usual middle ground is to allow users to consent only to low-risk permissions from verified publishers and send everything else through the admin consent workflow. There's a full walkthrough in admin consent workflow and user consent (https://azureblog.co.uk/posts/admin-consent-workflow-and-user-consent/). Sources - Microsoft Graph: defaultUserRolePermissions resource type (https://learn.microsoft.com/graph/api/resources/defaultuserrolepermissions) - Microsoft Graph: Update authorizationPolicy (https://learn.microsoft.com/graph/api/authorizationpolicy-update) - Microsoft Learn: Update-MgPolicyAuthorizationPolicy (https://learn.microsoft.com/powershell/module/microsoft.graph.identity.signins/update-mgpolicyauthorizationpolicy) - Microsoft 365 Message Center: MC1506733, Review who can create agents in Microsoft Entra --- # From November, every user can create agent blueprints in Entra unless you turn it off URL: https://azureblog.co.uk/posts/users-can-create-agent-blueprints/ Published: 2026-10-14 Tags: Entra ID, Security, What's new > Message Center MC1506733: starting in early November 2026, default users can create agent identity blueprints unless an admin switches off a new user setting. What a blueprint controls, who's affected, and how to turn it off before the rollout. Microsoft is changing who can create agents in Entra. From early November 2026, ordinary users with no admin role will be able to create agent identity blueprints unless you turn off a new setting. The rollout is expected to finish by late November. The setting is already in the admin centre, so you can make the decision now. It takes effect when the rollout reaches your tenant. ## Why blueprints matter Every agent identity in Entra is created from a blueprint. Microsoft describes it as the template that "establishes the foundation for how agents are created, authenticated, and managed". That makes it more than a label: - Credentials live on the blueprint. The secrets, certificates or federated credentials used to authenticate its agent identities are configured there. - Permissions flow down. OAuth permissions granted to a blueprint are granted to every agent identity created from it. - Policies apply to the whole family. Conditional Access can target a blueprint and every agent created from it, and disabling a blueprint stops all its agents signing in. - The creator becomes the owner. Whoever creates a blueprint is automatically made owner of the blueprint and its principal, and owners can create agent identities from it without an Agent ID role. Creating a blueprint doesn't grant access to company data on its own. Permissions still need consent. But it does put a reusable, credential-carrying template for agents into the hands of whoever made it. Most organisations will want that decided by whoever owns AI governance, not left as self-service. ## Who's affected - Affected: default users, meaning anyone without a built-in or custom Entra role. - Not affected: admins and users with the Agent ID Developer role can still create blueprints whatever the setting says. - Not affected: existing blueprints, the agent identities already created from them, and the requirements in platforms such as Microsoft Foundry and Security Copilot. ## How to turn it off - Sign in to the Microsoft Entra admin centre. - Go to Entra ID > Users > User settings. - Under Default user role permissions, find the agent blueprints setting. Microsoft's notice calls it Users can create agent blueprints; some tenants currently show it as Users can register agent identity blueprints. - Set it to No and select Save. Then give the Agent ID Developer role to the people who should build agents, ideally through PIM so it's time-bound and reviewed. This is separate from Users can register applications, which sits just above it. Turning one off doesn't change the other, so check both. ## Should you leave it on? If you've already decided that anyone can build agents and you govern them after the fact, Microsoft says no action is needed. For everyone else, switch it off now and open it up deliberately later. It's much easier than finding out in December how many blueprints your users have made. For the wider picture, see governing AI agent identities in Entra (https://azureblog.co.uk/posts/governing-ai-agent-identities-in-entra/). Sources - Microsoft 365 Message Center: MC1506733, Action may be required: Review who can create agents in Microsoft Entra (13 October 2026) - Microsoft Learn: Agent identity blueprints in Microsoft Entra Agent ID (https://learn.microsoft.com/entra/agent-id/agent-blueprint) - Microsoft Learn: Create an agent identity blueprint (https://learn.microsoft.com/entra/agent-id/create-blueprint) - Microsoft Learn: How are agent identities created? (https://learn.microsoft.com/entra/agent-id/agent-id-creation-channels) --- # What's actually inside an Azure region? From the planet to one server, then we break it URL: https://azureblog.co.uk/posts/inside-an-azure-region/ Published: 2026-10-13 Tags: Azure, Security > Pick UK South from a dropdown and you're choosing a real place: zones, buildings, fences, generators, racks and hosts. Here's what's inside, layer by layer, using only what Microsoft publishes. Then choose how your app is deployed, knock out a server, a zone or the whole region, and see what survives. Every deployment starts with the same small decision. You open a form, find the Region dropdown and pick something like UK South. It feels like a setting. It's actually a choice about which buildings, power supplies and fibre your app depends on, and which failures it can ride out. This post walks down through every layer, from the global network to a single server, then breaks things on purpose. Everything here comes from Microsoft's own documentation, linked at the end. ## The layers, top to bottom [Diagram: What you're really choosing when you pick a region.] ### The network that ties it together Microsoft describes its global network as one of the largest in the world, spanning more than 500,000 miles and connecting more than 80 Azure regions. It connects with more than 4,000 internet partners at more than 190 locations. Traffic between Azure datacentres or regions stays on Microsoft's network rather than crossing the public internet. ### Geography and region A geography is a distinct market. A region is a set of datacentres deployed within a latency-defined perimeter: close enough together to behave like one place, but not one single building. When you deploy to UK South you never pick a datacentre. You pick the region, and optionally a zone. ### Availability zones Most regions that support zones have three of them. Microsoft's definitions are precise, so here they are with as little paraphrasing as possible: - A zone is a logical grouping of one or more physically separate datacentres, with independent power, cooling and networking. - Zones are typically several kilometres apart, and usually within 100 kilometres of each other. - They're linked by a high-performance network with a round-trip latency of less than about 2 milliseconds. - Traffic between zones is always encrypted, and Microsoft places them using more than 30 viability and risk-based criteria. One detail catches people out: zone numbers are logical. Your "zone 1" in one subscription isn't necessarily the same physical zone as "zone 1" in another subscription. If two subscriptions need to line up, check the mapping rather than assuming. [Diagram: Zonal and zone-redundant sound alike but put the work in different places.] ## Inside the building Microsoft publishes a surprising amount about its datacentres. Access is layered, and each layer is checked separately: - Access request. You need a valid business reason, access is need-to-access only, and it expires. Visitors are badged as escort only. - Facility perimeter. Typically tall steel and concrete fences around every inch of the perimeter, cameras monitored at all times, guard patrols and bollards. - Building entrance. Trained, background-checked security officers who also patrol and watch the cameras. - Inside the building. Two-factor authentication with biometrics, and only into the parts you're approved for, for the time you're approved for. - Datacentre floor. Full body metal detection on the way in and out, only approved devices allowed, and cameras on the front and back of every server rack. Power is layered too. Uninterruptible power supplies and banks of batteries cover short disruptions, emergency generators take over for longer outages and planned maintenance, and there are fuel reserves on site. When a disk reaches end of life it's wiped using a process that complies with NIST 800-88. If it can't be wiped, it's destroyed: disintegrated, shredded, pulverised or incinerated, and the destruction is recorded. ### The host At the bottom of all this is a physical server, which Azure calls a host. A single VM runs on one host, and most VMs share their host with other customers' VMs. For durability, Azure keeps three healthy replicas of your data in the primary location. Two terms matter once you run more than one VM: - Fault domains are groups of VMs that share a common power source and network switch. An availability set can use up to 3. - Update domains are groups that can be restarted at the same time during maintenance. An availability set can use up to 20. Microsoft's VM documentation is clear that availability sets don't offer the same resiliency as availability zones, and recommends zones when reliability is the priority. ## Region pairs Many regions are paired with another region in the same geography. UK South is paired with UK West. Pairs get staggered platform updates, so both aren't updated at once, and priority in recovery if there's a wide outage. Some services also use the pair as their default replication target. Two things are easy to miss. Many newer regions don't have a pair at all, and Microsoft says pairing doesn't automatically make your app more resilient. You still have to replicate your data and fail over. Azure Site Recovery can replicate VMs to almost any region, including regions that aren't the pair. ## Now break it Pick how your app is deployed, then pick what fails. The diagram and verdict use the behaviour Microsoft documents for virtual machines. [Interactive tool: open the post on azureblog.co.uk to use it.] Assumes two or more VMs where the option says so, with a zone-resilient load balancer doing health checks. Other services, such as zone-redundant storage or databases, handle zone failover for you, so check each service's reliability guide. ## A sensible default - Production that people rely on: run across zones. It costs at least three VMs instead of one, but it covers servers, racks and whole zones. - Anything that must survive a region: replicate to a second region and rehearse the failover. A plan you've never run is a guess. - Monitor for zone problems yourself. Microsoft doesn't automatically notify you when a zone is down, and work in flight on a failed VM is likely lost. - Check zone mappings if you place zonal resources in several subscriptions and expect them to line up. - Single VMs are fine for dev, test and anything that can wait. Just make that a choice rather than a default. ## FAQ **How many datacentres are in a region?** Microsoft doesn't publish a count per region. A region is a set of datacentres, and each availability zone is one or more of them. **Does every region have availability zones?** No. Most regions that support zones have three, and the list of zone-enabled regions is on Microsoft Learn. UK South supports zones. **If I use zone-redundant services, do I still need a second region?** Only if your app must survive the loss of a whole region. Zones protect you from a datacentre or zone failure inside one region. A second region is the only protection against losing the region itself. **Do I have to use the paired region for disaster recovery?** No. Some services replicate to the pair by default, but for VMs you can choose almost any region as the secondary. Data residency rules may limit which regions you can use. Sources - Microsoft Learn: What are availability zones? (https://learn.microsoft.com/azure/reliability/availability-zones-overview) - Microsoft Learn: Azure region pairs and nonpaired regions (https://learn.microsoft.com/azure/reliability/cross-region-replication-azure) - Microsoft Learn: Microsoft global network (https://learn.microsoft.com/azure/networking/microsoft-global-network) - Microsoft datacenters: geographies, regions and availability zones (https://datacenters.microsoft.com/) - Microsoft Learn: Azure facilities, premises and physical security (https://learn.microsoft.com/azure/security/fundamentals/physical-security) - Microsoft Learn: Azure infrastructure availability (https://learn.microsoft.com/azure/security/fundamentals/infrastructure-availability) - Microsoft Learn: Availability sets overview (https://learn.microsoft.com/azure/virtual-machines/availability-set-overview) - Microsoft Learn: Reliability in Azure Virtual Machines (https://learn.microsoft.com/azure/reliability/reliability-virtual-machines) --- # Microsoft's deadline week: four products retire tomorrow, and Secure Boot's last 2011 certificate expires next Monday URL: https://azureblog.co.uk/posts/secure-boot-certificates-and-october-retirements/ Published: 2026-10-12 Tags: Intune, Security, What's new > 13 October 2026 ends support for Windows 11 24H2 Home and Pro, Windows 10 2016 LTSB and Office LTSC 2021, and moves Windows Server 2022 into extended support. On 19 October the Windows Production PCA 2011 certificate expires. Pick what you run for your own action list, and check any device's Secure Boot status in seconds. Tomorrow is one of the busiest days on Microsoft's retirement calendar, and the week has a sting in its tail. Four products reach a lifecycle milestone on Tuesday 13 October 2026. Then on Monday 19 October, the last of the original 2011 Secure Boot certificates expires: the one that signs the Windows boot manager itself. [Interactive tool: open the post on azureblog.co.uk to use it.] Countdown to 19 October (UTC). Devices keep booting afterwards; the ones without the 2023 certificates just stop getting boot-level security fixes. None of these switch anything off. But each one stops a device getting something it needs, and the Secure Boot change affects almost every Windows device you manage. ## What affects you? Tick what you run and you'll get an action list in date order that you can copy into a ticket or a to-do app. [Interactive tool: open the post on azureblog.co.uk to use it.] ## The Secure Boot certificates Secure Boot checks that everything loaded before Windows starts is signed by someone the firmware trusts. Those trust anchors are certificates stored in the device's UEFI firmware, and Microsoft's originals date from 2011. They're being replaced by 2023 versions. Two of them expired in June (one has two replacements, so it appears twice below). The last one goes next Monday. - - UEFI firmwareSecure Boot DB / KEKtrusted certificates Windows boot managerbootmgfw.efi, signed by… PCA 2011 · expires UEFI CA 2023 ✓ WindowsBitLocker, Defender,your apps Firmware only starts a boot manager signed by a certificate it trusts. The boot manager is signed by the expiring PCA 2011 certificate. The update adds Windows UEFI CA 2023 to firmware and installs a boot manager signed with it. | Expiring certificate | Expired or expires | Replaced by | What it's for | Microsoft Corporation KEK CA 2011 | June 2026 | Microsoft Corporation KEK 2K CA 2023 | Signs updates to the allowed (DB) and blocked (DBX) lists | Microsoft UEFI CA 2011 | June 2026 | Microsoft UEFI CA 2023 | Signs third-party boot loaders and EFI applications | Microsoft UEFI CA 2011 | June 2026 | Microsoft Option ROM UEFI CA 2023 | Signs third-party option ROMs, such as on graphics and network cards | Microsoft Windows Production PCA 2011 | 19 October 2026 | Windows UEFI CA 2023 | Signs the Windows boot manager ### What actually happens on 19 October Microsoft is clear that devices without the new certificates keep starting and running normally, and keep installing ordinary Windows updates. Nobody's laptop stops booting. What they lose is the ability to get new protections for the early boot process: updated boot managers, new entries in the DB and DBX lists, and fixes for boot-level vulnerabilities. That's exactly the layer bootkits target, and over time it weakens protections such as BitLocker that depend on a trusted boot chain. A device that misses this change is stuck with today's boot security for good. [Diagram: A Windows device after 19 October 2026.] ### Check a device in 30 seconds Windows records progress in the registry. Microsoft's guidance is to read UEFICA2023Status, which moves from NotStarted to InProgress to Updated, and to check UEFICA2023Error for anything that went wrong. Run this in an administrator PowerShell window: ``` $s = Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" -ErrorAction SilentlyContinue [pscustomobject]@{ SecureBootOn = Confirm-SecureBootUEFI Status = $s.UEFICA2023Status Error = $s.UEFICA2023Error CA2023InDb = [Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match "Windows UEFI CA 2023" } | Format-List ``` Then paste what it prints here. It's checked in your browser and nothing is sent anywhere: [Interactive tool: open the post on azureblog.co.uk to use it.] Don't rely on the WindowsUEFICA2023Capable value you may see nearby: Microsoft says not to use it for status. In the Event Viewer, the Secure Boot DB and DBX update events 1801 and 1808 also show each device's progress. To check every device at once, run the same script as an Intune Remediations (https://azureblog.co.uk/posts/intune-remediations-scripts/) detection script and read the output column. ### Roll it out with Intune Microsoft added three settings to the Intune settings catalog for this. Create a Windows 10 and later › Settings catalog profile, search for Secure Boot, and you'll find: | Setting | What it does | Enable Secureboot Certificate Updates | Set to Enabled and Windows starts deploying the 2023 certificates and the new boot manager. | Configure Microsoft Update Managed Opt In | Lets Microsoft deploy them in a controlled rollout. Needs devices to send required diagnostic data. | Configure High Confidence Opt-Out | Enabled blocks the automatic deployment that otherwise arrives through monthly updates on devices Microsoft rates as high confidence. For most organisations the first setting, enabled for a pilot group and then everyone, is the one that matters. Before you assign it: - Start with your OEM's firmware. Microsoft's first recommendation is the latest firmware from the device maker. When the update fails, the error recorded in UEFICA2023Error often comes from firmware. - It isn't instant. A scheduled task processes the setting every 12 hours, and the boot manager part needs a normal restart. - It can't be undone from Windows. Once the certificates are written to firmware, removing them means going into the firmware itself. That's why you pilot first. - Check your BitLocker recovery keys are escrowed before changing anything in the boot chain. That's good practice for any firmware or boot change. - Known issue on Pro editions. Microsoft notes the policy can fail on Windows 10 and 11 Pro with Intune error 65000, and its guidance covers the licensing fix. ### Without Intune For servers and devices you manage yourself, Microsoft documents a registry trigger. Setting AvailableUpdates to 0x5944 tells Windows to add the 2023 certificates, update the KEK and install the new boot manager: ``` reg add HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update" ``` Restart when convenient, then run the check again. There's a Group Policy route too. Don't edit AvailableUpdatesPolicy by hand: that's the value Intune and Group Policy write. ## Windows 11 24H2 Home and Pro Home and Pro devices on version 24H2 get their last security update tomorrow. Enterprise and Education editions of 24H2 are supported until 12 October 2027, so most managed corporate devices aren't affected yet. Look for Pro devices in particular: small offices, contractors' laptops and anything bought retail often run Pro. Microsoft's recommended path is Windows 11 version 25H2. In Intune, a feature update policy targeting 25H2 moves them across, and the Windows feature update reports show which devices are still on 24H2. ## Windows 10 Enterprise 2016 LTSB The 2016 Long-Term Servicing Branch reaches the end of its ten years tomorrow. LTSB tends to sit on devices nobody thinks of as PCs: kiosks, factory and lab machines, digital signage and medical carts. That makes them easy to forget. Microsoft's recommended move is Windows 11 Enterprise LTSC 2024. If a device can't move in time, Microsoft says Extended Security Updates are available for LTSB 2016. Treat that as a bridge, not a plan. ## Office LTSC 2021 Volume-licensed Office LTSC 2021 Standard, for Windows and Mac, reaches the end of its support tomorrow and stops getting security updates. The options are Microsoft 365 Apps, which stays current and supported, or Office LTSC 2024 if you need a perpetual, non-subscription version for the same kind of locked-down devices. ## Windows Server 2022 moves to extended support This is the gentlest of the five. Windows Server 2022 leaves mainstream support tomorrow and enters extended support, which keeps security updates coming until 14 October 2031 at no extra cost. Extended support is security updates only, so Microsoft's message is to start planning for Windows Server 2025. ## Checklist - Secure Boot status checked across the estate with UEFICA2023Status - Latest OEM firmware deployed where the update fails - Intune Secure Boot policy piloted, then assigned to everyone - BitLocker recovery keys escrowed before changing boot components - Windows 11 24H2 Home and Pro devices moved to 25H2 - LTSB 2016 devices found, with a move to LTSC 2024 or ESU in place - Office LTSC 2021 installs replaced with Microsoft 365 Apps or Office LTSC 2024 - Windows Server 2025 on the roadmap for your 2022 servers **Will devices stop booting when the Secure Boot certificate expires?** No. Microsoft says devices without the 2023 certificates keep starting and running normally, and keep getting ordinary Windows updates. They just can't receive new boot-level security fixes. **Do I have to do anything if Windows Update is on?** Many devices get the certificates automatically through monthly updates, especially ones Microsoft rates as high confidence. Don't assume it: check UEFICA2023Status. Devices with older firmware, IT-managed update settings or limited diagnostic data are the likeliest to be missed. **Can I remove the new certificates if something goes wrong?** Not from Windows. Once they're written to firmware they have to be cleared through the firmware's own settings, which is why you should update firmware first and pilot on a small group. **Does Windows Server 2022 stop getting security updates?** No. Only mainstream support ends. Security updates continue until 14 October 2031. Sources - Microsoft Support: Windows Secure Boot certificate expiration and CA updates (KB5062710) (https://support.microsoft.com/kb/5062710) - Microsoft Support: Registry key updates for Secure Boot (KB5068202) (https://support.microsoft.com/help/5068202) - Microsoft Support: Microsoft Intune method of Secure Boot updates (KB5073196) (https://support.microsoft.com/help/5073196) - Microsoft Learn: Windows 11 Home and Pro lifecycle (https://learn.microsoft.com/lifecycle/products/windows-11-home-and-pro) - Microsoft Learn: Windows 10 2016 LTSB lifecycle (https://learn.microsoft.com/lifecycle/products/windows-10-2016-ltsb) - Microsoft Learn: Office LTSC 2021 lifecycle (https://learn.microsoft.com/lifecycle/products/office-ltsc-2021) - Microsoft Learn: Windows Server 2022 lifecycle (https://learn.microsoft.com/lifecycle/products/windows-server-2022) --- # Windows Server 2012 and 2012 R2: the last security update ships tomorrow URL: https://azureblog.co.uk/posts/windows-server-2012-esu-ends/ Published: 2026-10-12 Tags: Azure, Security, What's new > Extended Security Updates for Windows Server 2012 and 2012 R2 end with the October 2026 Patch Tuesday. There's no fourth year, not even on Azure. Here's what stops, who's still running these servers and why, how to find yours, and what to do with them. Tomorrow, Tuesday 13 October 2026, Microsoft releases the last security updates Windows Server 2012 and 2012 R2 will ever get. Extended Security Updates (ESU) Year 3 ends at 06:59 Pacific time on Wednesday 14 October, which is 14:59 in the UK. After that, there are no more patches for these versions, whatever you pay and wherever the server runs. That's a bigger deal than the original end of support in October 2023. Then, there was a paid safety net. This time there isn't one. ## How we got here | Date | What happened | 25 November 2013 | Windows Server 2012 R2 lifecycle begins | 9 October 2018 | Mainstream support ended: no more new features or non-security fixes | 10 October 2023 | Extended support ended. ESU Year 1 began for those who paid, or who moved to Azure | 8 October 2024 | ESU Year 1 ended, Year 2 began | 14 October 2025 | ESU Year 2 ended, Year 3 began | 13 October 2026 | Last ESU security update. Coverage ends early on 14 October Windows Server 2012 (without R2) follows the same ESU dates. ## What actually ends ESU only ever covered one thing: security updates rated Critical or Important. No new features, no non-security fixes on request, and no general support. From Wednesday, even that stops, for every route people used to get it: - Azure VMs. ESU was free on Azure, and on Azure Local, Azure VMware Solution, Azure Dedicated Host, Azure Nutanix Solution and Azure Stack Hub and Edge. Free ends too. A 2012 R2 VM in Azure is as unpatched as one under a desk. - Azure Arc. Servers enrolled through Arc were billed monthly. There's nothing left to enrol in. - Volume licensing. Organisations with Software Assurance bought each year at 100% of the full licence price and activated a Multiple Activation Key (MAK). There's no Year 4 key to buy. - Support tickets. Microsoft's FAQ is blunt: without ESU, you can't log a support ticket for 2012 or 2012 R2, even with a support plan. There's no fourth year. Windows Server 2008 and 2008 R2 got one extra year of ESU on Azure only. Microsoft's ESU FAQ limits that to 2008. For 2012, coverage is "up to three years following the end of support date", and that's now been used up. ### What doesn't change on Wednesday Nothing switches off. The servers keep booting, activation keeps working, and applications keep running. What changes is that every security vulnerability found in these versions from now on stays open for good, and each month's security updates for newer versions become a list of vulnerabilities your 2012 servers will never be fixed for. It also changes your compliance position. Most frameworks require supported, patched software. Cyber Essentials, for example, expects software on in-scope devices to be supported by the vendor and updated within 14 days of a high or critical fix being released. A 2012 R2 server can't meet that from Wednesday. [Diagram: A Windows Server 2012 R2 machine either side of the deadline.] ## Who's still running it, and why Nobody publishes reliable figures for how many 2012 servers are left. The numbers you'll see quoted mostly come from companies selling migrations or third-party support. I'm also not going to name organisations: there's no trustworthy public list, and calling out specific companies as running unpatched servers would be both guesswork and a gift to attackers. What's well understood is where they survive and why. It's rarely neglect. It's usually something holding the server in place: | Where | What's on them | What keeps them there | Manufacturing, utilities and other operational technology | Control system servers, historians, HMI and engineering workstations, building management | The industrial software vendor only certifies a specific OS version. Upgrading can mean revalidating a production line or stopping a plant. | Healthcare and laboratories | Imaging, lab instruments, pathology and pharmacy systems, integrations between clinical systems | Systems tied to validated hardware or regulated configurations, where any change means revalidation by the supplier. | Finance, insurance and professional services | Line-of-business apps, reporting, document and case management, old SQL Server instances | A vendor that never recertified the app, or went out of business, plus custom code nobody wants to touch. | Public sector and education | Departmental apps, file and print, timetabling and records systems | Budget cycles, small teams and long procurement for replacements. | Everyone | Domain controllers, DNS, DHCP, file and print, and "appliance" servers nobody owns | It works, nobody's sure what depends on it, and it never made it onto a project plan. That last row is the most common, and the most fixable. The first three are where the real risk sits, because those servers often support critical services. The US cybersecurity agency CISA lists running unsupported software in critical services as its number one bad practice, saying it "is dangerous and significantly elevates risk", and that it's "especially egregious in technologies accessible from the Internet". ## Find every one you have You can't plan for servers you don't know about. Check from more than one angle, because each source misses something. Active Directory, including machines that haven't signed in for a while: ``` Get-ADComputer -Filter 'OperatingSystem -like "*Server 2012*"' -Properties OperatingSystem, LastLogonDate | Sort-Object LastLogonDate -Descending | Select-Object Name, OperatingSystem, LastLogonDate ``` Microsoft Defender for Endpoint advanced hunting, for anything onboarded: ``` DeviceInfo | where Timestamp > ago(7d) | where OSPlatform startswith "WindowsServer2012" | summarize arg_max(Timestamp, OSPlatform, OSBuild, PublicIP) by DeviceName | order by DeviceName asc ``` Azure Resource Graph, for Azure VMs and Arc-enabled servers. This relies on the OS name Azure reports, so VMs need to be running: ``` resources | where type in~ ("microsoft.compute/virtualmachines", "microsoft.hybridcompute/machines") | extend os = tostring(coalesce(properties.extended.instanceView.osName, properties.osSku, properties.osName)) | where os has "2012" | project name, type, os, resourceGroup, subscriptionId, location ``` Compare the three lists. Servers that appear in AD but not in Defender are the ones to worry about first, because nothing is watching them. ## Your options | Option | When it fits | Watch out for | In-place upgrade | The app supports a newer OS and you want to keep the server. 2012 R2 upgrades directly to 2016, 2019 or 2025. Windows Server 2025 can jump up to four versions, so 2012 R2 to 2025 is one step. | 2012 (not R2) can only go to 2012 R2 or 2016. 2012 R2 can't go straight to 2022. You can't switch between Server Core and Desktop Experience during an upgrade. Take a backup or snapshot first. | Migrate to a new server | Most cases: build a clean, supported server and move the roles, data and apps across. | Takes longer, but you leave years of configuration drift behind. For domain controllers, the cleaner route is to add new DCs on a supported version, move the roles across and demote the old ones. | Replace the app | The vendor has a supported version, or a SaaS alternative exists. | Often the real fix for servers held back by an uncertified app. | Retire it | Nobody can say what it's for. | Turn it off (don't delete it) for a few weeks and see who complains. More of these exist than anyone expects. | Isolate it | Genuinely can't move yet, for example a vendor-locked control system. | A temporary risk decision, not a fix. See below. Moving a 2012 server to Azure was a popular option while ESU was free there. After tomorrow that no longer buys you anything. It's worth doing only if you upgrade or migrate as part of the move. ## If one can't move yet The UK's National Cyber Security Centre is clear that "the only fully effective way to mitigate this risk is to stop using the obsolete product". If you have to keep one for a while, its guidance on obsolete products boils down to making the server hard to reach and less damaging if it's compromised: - Cut its routes in. No internet access, no email, no web browsing, no removable media. Use technical controls, not just policy. - Put it in its own network zone with only the specific traffic flows it needs, enforced by a network firewall. Don't rely on the server's own firewall, because a compromised server can turn it off. - Take things off it. Move services that don't need to be there onto supported servers, switch off anything non-essential, and keep sensitive data away from it. - Treat it as untrusted. No domain admin sign-ins from it, no remote desktop hosting, and constrained access to everything else. - Watch it closely. Collecting logs isn't enough on its own: someone has to act on them. - Write the risk down with an owner and a review date, and keep the migration on the plan. ## Checklist - Every 2012 and 2012 R2 server found, from AD, Defender and Azure Resource Graph - Each one has an owner and a decision: upgrade, migrate, replace, retire or isolate - Tomorrow's final security updates installed on every one that still has ESU - Anything left facing the internet taken off it this week - Domain controllers on 2012 or 2012 R2 replaced by new DCs on a supported version - Servers you have to keep isolated, monitored and recorded as an accepted risk with a review date **Will my 2012 servers stop working on Wednesday?** No. Nothing is switched off and activation isn't affected. They simply stop getting security updates, so they become steadily more exposed to every new vulnerability. **Can I buy a fourth year of ESU?** No. Microsoft's ESU FAQ caps 2012 and 2012 R2 at three years after end of support. The extra Azure-only year was for Windows Server 2008 and 2008 R2. **Doesn't running it in Azure keep it patched?** Only until tomorrow. Azure gave free ESU for the three ESU years. After 13 October 2026 there are no updates to deliver, on Azure or anywhere else. **Can I upgrade 2012 R2 straight to Windows Server 2025?** Yes, if it isn't clustered. Windows Server 2025 supports upgrading up to four versions at once, so 2012 R2 to 2025 is supported in one step. You can't go straight from 2012 R2 to 2022, and 2012 without R2 can only upgrade to 2012 R2 or 2016. Sources - Microsoft Learn: Windows Server 2012 R2 lifecycle (https://learn.microsoft.com/en-us/lifecycle/products/windows-server-2012-r2) - Microsoft Learn: Extended Security Updates FAQ (https://learn.microsoft.com/en-us/lifecycle/faq/extended-security-updates) - Microsoft Learn: How to get Extended Security Updates for Windows Server (https://learn.microsoft.com/en-us/windows-server/get-started/extended-security-updates-deploy) - Microsoft Learn: Windows Server upgrade overview (https://learn.microsoft.com/en-us/windows-server/upgrade/upgrade-overview) - NCSC: Managing obsolete products (https://www.ncsc.gov.uk/collection/device-security-guidance/managing-deployed-devices/obsolete-products) - NCSC: Cyber Essentials (https://www.ncsc.gov.uk/cyberessentials/overview) - CISA: Bad practices (https://www.cisa.gov/stopransomware/bad-practices) --- # Governing AI agent identities in Entra: sponsors, access packages and expiry URL: https://azureblog.co.uk/posts/governing-ai-agent-identities-in-entra/ Published: 2026-10-11 Tags: Entra ID, Governance, Security > Every AI agent with an Entra Agent ID needs a human who answers for it, access that runs out, and a plan for when its sponsor leaves. Here's how to set up sponsors, access packages and Lifecycle Workflows so agents don't become the next generation of orphaned service principals. Most tenants already have a graveyard of service principals: apps with secrets nobody rotates, permissions nobody remembers granting, and owners who left years ago. AI agents could make that much worse, because they're easy to create and they multiply. A team that builds one support agent this month may run fifty next quarter. Microsoft Entra Agent ID (https://azureblog.co.uk/posts/entra-agent-id-identities-for-ai-agents/) gives each agent its own identity, and with it the governance hooks you'd want for any identity: a named person who's accountable, access that's requested and approved, assignments that expire, and automatic hand-over when people move on. None of it happens unless you set it up. This post walks through the pieces. ## Owners, sponsors and managers are different jobs Agent ID splits responsibility three ways. Getting this right first makes everything else simpler. | | Owner | Sponsor | Manager | Responsible for | The technical side: settings, credentials, configuration | The business side: whether the agent should exist and what it should access | Where the agent sits in the organisation | Applies to | Agent identities and blueprints | Agent identities, blueprints, blueprint principals and agent user accounts | Agent user accounts | Who can be one | Users (including guests) and service principals. Not groups | Users (including guests), dynamic membership groups, and assigned Microsoft 365 groups | Individual users | Required? | No | Yes, when you create an agent identity or blueprint | No The sponsor is the important one for governance. Sponsors can disable an agent, soft-delete it and change its sponsors, and they get the expiry notices for its access. They can't change its settings, and they can't re-enable or restore an agent they've disabled or deleted. That has to go back to an owner or an administrator, which is a sensible brake on a business user switching things on and off. [Diagram: What each relationship can do to an agent identity.] ### Rules worth knowing about sponsors - Someone is always set. If a person creates an agent identity and names no sponsor, they become its sponsor. If they name someone else, they aren't added. An app creating agents with app-only permissions must set at least one sponsor itself. - Use groups, but the right kind. An agent identity or blueprint can have up to 100 sponsors, no more than 5 of them groups. Dynamic membership groups and assigned Microsoft 365 groups work. Role-assignable groups and assigned security groups don't. Every member of a sponsoring group gets sponsor rights. - Match them up. If an agent has both an agent identity and an agent user account, Microsoft recommends the same user or group as sponsor on both, with the agent identity's sponsor treated as the primary one. - These aren't admin roles. Owner and sponsor are set per agent, separately from Entra roles such as Agent ID Administrator (https://azureblog.co.uk/roles/entra/agent-id-administrator/). Being a sponsor of one agent gives you nothing over the others. ## Give agents access through access packages The quickest way to give an agent what it needs is to grant it directly: add it to a group, consent to a Graph permission. That's also how you end up with access nobody can explain a year later. Entitlement management access packages are the alternative. In Microsoft's words, they make sure "agent access assignments are intentional, auditable, and time-bound". They also scale. If you run a fleet of customer support agents that all need the same groups and permissions, one access package covers all of them. An access package for agents can include: - Security group memberships - Microsoft Entra roles, from the list of roles allowed for agents - API permissions, application or delegated, for Microsoft Graph or your own apps (in preview) Don't add application roles, SAP roles or SharePoint Online site roles. That also means you can't reuse an existing package that contains any of them, so create a new one for agents. ### Set one up You need at least Identity Governance Administrator (https://azureblog.co.uk/roles/entra/identity-governance-administrator/). Adding API permissions or directory roles to a package needs Global Administrator, and doing so marks the catalog as privileged. - In the Entra admin centre, go to ID Governance › Entitlement management › Access packages › New access package, and pick a catalog. - Under Resource roles, add the groups, roles or API permissions. - Under Requests, choose For users, service principals, and agent identities in your directory, then All agents. If some of your agents still run as ordinary service principals, add a second policy for All Service principals. - Set up approval stages. A sensible default is one stage, approved by the resource owner. - On Lifecycle, set how long assignments last. This is the part that matters most. ### Who asks, and what happens at expiry There are three ways an agent gets assigned: - The agent asks for itself, by creating an access package assignment request through Microsoft Graph. - Its sponsor asks on its behalf, which keeps a person in the loop. - An administrator assigns it directly. [Diagram: An agent's access from request to expiry.] As the end date approaches, the sponsor is notified. If the policy allows it, they can ask for an extension, which can send it back through approval. If nobody acts, the assignment expires on its end date and the agent loses the access. That's the behaviour you want: an abandoned agent quietly loses its permissions instead of keeping them for ever. ## When a sponsor moves or leaves A sponsor who leaves is how agents become orphans. Microsoft's documentation says Entra reassigns sponsorship to the departing sponsor's manager. Lifecycle Workflows has three tasks so you can control and announce that hand-over as part of your existing mover and leaver process: | Task | What it does | Send email to manager about sponsorship changes | Tells the manager that their report's sponsorships are moving | Send email to co-sponsors about sponsor changes | Tells the agent's other sponsors | Transfer agent identity sponsorships to manager | Moves the sponsorships to the manager All three are mover and leaver tasks, so they're only available in mover or leaver workflow templates. Add them to the leaver workflow you already run, under ID Governance › Lifecycle workflows › Workflows, with at least Lifecycle Workflows Administrator (https://azureblog.co.uk/roles/entra/lifecycle-workflows-administrator/). Then the manager knows they've inherited a set of agents, and can keep them, hand them on or retire them. ## Know what agents you have Go to Entra ID › Agents › Agent identities. Add the Owners and Sponsors and Blueprint App ID columns and look for agents whose only sponsor is someone who's already left, or a group nobody manages. Viewing the list needs no admin role. Changing agents needs Agent ID Administrator or Cloud Application Administrator, unless you own the agent. To see what agents are actually doing, filter the sign-in logs for agent identities. Microsoft documents this query against the Graph beta endpoint: ``` GET https://graph.microsoft.com/beta/auditLogs/signIns?$filter=signInEventTypes/any(t: t eq 'servicePrincipal') and agent/agentType eq 'AgentIdentity' ``` For the wider picture of who holds which admin roles, including any you've given to agents, the Access Map (https://azureblog.co.uk/tools/access-map/) shows Entra and Azure roles side by side. ## Retiring an agent: disable first Microsoft recommends disabling before deleting. Disabling stops the agent getting tokens straight away and leaves everything in place, so it's easy to undo. You can disable one agent, select several and disable them in a batch, or disable a whole blueprint, which also stops new agents being created from it. Deleting is less forgiving: - Deleting a blueprint cascades. Entra removes every agent identity and agent user account created from it. The clean-up runs in the background and can take hours or days. - You have 30 days. Deleted objects can be restored for 30 days. Restore the blueprint principal before the clean-up runs and its agents are untouched. Restore it after, and you have to restore each agent one by one. - Deleted agents still count. Soft-deleted agents count towards your directory quota, and towards the limit of 250 agent identities per blueprint for apps using app-only permissions, until they're permanently deleted. - Expect odd audit entries. Cascade deletions show up as Delete service principal, initiated by an application called Delete Agent Identities Task, with no actor app ID. That's Entra's own background process. Be careful with blanket disables. Microsoft warns that disabling agent identities across the board can break existing agents, degrade Microsoft product experiences, and push teams towards less transparent app or service principal identities. Check the impact first. ## Licensing Microsoft lists the governance features for agents (access packages, sponsor tasks in Lifecycle Workflows) as needing either: - Microsoft 365 E7, which includes Agent 365 and the Microsoft Entra Suite, or - Microsoft Agent 365 with at least Microsoft Entra ID P1 or Microsoft 365 E3. Check the ID Governance licensing page (https://learn.microsoft.com/en-us/entra/id-governance/licensing-fundamentals) against what you own before you build workflows around these features. ## Checklist - Every agent identity has a sponsor who still works here, ideally a dynamic or Microsoft 365 group rather than one person - The same sponsor is set on an agent's identity and its user account - New agent access comes through access packages with an end date, not direct grants - The sponsor tasks are in your leaver (and mover) Lifecycle Workflows - Someone reviews Entra ID › Agents › Agent identities every month - Agents are disabled before they're deleted, and blueprints are deleted only when retiring every agent made from them **Is a sponsor the same as an owner?** No. An owner manages the agent technically, including credentials and settings. A sponsor answers for whether it should exist and what it can access. Sponsors can disable or soft-delete an agent but can't change its settings or bring it back. **Can an agent request its own access?** Yes. An agent can create an access package assignment request through Microsoft Graph, and it goes through the same approval as any other request. Its sponsor can also request on its behalf. **What happens to an agent when its sponsor leaves?** Microsoft says Entra reassigns sponsorship to the sponsor's manager. Add the three sponsor tasks to your leaver workflow so the manager and any co-sponsors are told, and the transfer happens as part of your normal process. Sources - Microsoft Learn: Owners, sponsors and managers in Microsoft Entra Agent ID (https://learn.microsoft.com/en-us/entra/agent-id/agent-owners-sponsors-managers) - Microsoft Learn: Access packages for agent identities (https://learn.microsoft.com/en-us/entra/agent-id/agent-access-packages) - Microsoft Learn: Lifecycle Workflows tasks for agent identity sponsors (https://learn.microsoft.com/en-us/entra/id-governance/agent-sponsor-tasks) - Microsoft Learn: Governing agent identities (https://learn.microsoft.com/en-us/entra/id-governance/agent-id-governance-overview) - Microsoft Learn: Manage agent identities in your organisation (https://learn.microsoft.com/en-us/entra/agent-id/manage-agent-identities-organization) - Microsoft Learn: Agent identity deletion (https://learn.microsoft.com/en-us/entra/agent-id/concept-agent-identity-deletion) --- # Domainless SAML federation: let partners sign in with their own IdP, whatever their email domain URL: https://azureblog.co.uk/posts/domainless-saml-federation-b2b/ Published: 2026-10-10 Tags: Entra ID, Security > SAML/WS-Fed federation for B2B guests used to depend on the guest's email domain matching the partner's IdP. Domainless federation is now generally available, and it routes sign-in by the IdP's Issuer URI instead. SAML/WS-Fed IdP federation lets your tenant trust a partner's own identity provider. Their users redeem your B2B invitations and sign in with the accounts they already have, so you don't create new credentials or a Microsoft account for them. Microsoft redirects them to their IdP, then brings them back to your tenant once they've signed in. It has always had one awkward rule: the domain in the guest's email address had to match a domain configured on the IdP. That's fine when everyone at the partner is @fabrikam.com. It breaks for contractors, freelancers and partners whose users have addresses on another domain, or even on gmail.com. Domainless SAML IdP federation, now generally available for workforce tenants, removes that check. ## What goes wrong without it With domain-based federation, Entra compares the email claim in the SAML assertion with the domains on the IdP configuration. If they don't match, sign-in fails with: ``` AADSTS5000819: SAML Assertion is invalid. Email address claim is missing or does not match domain from an external realm. ``` You can look that up in the AADSTS error lookup (https://azureblog.co.uk/tools/aadsts/), and paste the failing response into the SAML decoder (https://azureblog.co.uk/tools/saml/) to see exactly which email address the partner's IdP sent. ## How domainless federation works With the Domainless option ticked, Entra no longer looks at the user's email domain. It routes the authentication request to the IdP by its Issuer URI. When you invite a guest, you add a domain_hint parameter to the invitation's redirect URL, set to that Issuer URI. When they redeem, Entra uses it to send them to the right IdP. [Diagram: What decides which IdP a guest is sent to.] After redemption, Entra updates the guest's user object with the external IdP association. From then on they can sign in to your apps directly, without the hint. [Diagram: First sign-in for a guest invited with a domain_hint.] ## What the partner's IdP needs to send The SAML requirements are the same as for domain-based federation. For a workforce tenant: | Setting | Value | Assertion Consumer Service | https://login.microsoftonline.com/login.srf | Audience | https://login.microsoftonline.com// (recommended) | Issuer | The partner IdP's issuer URI. It must be a valid URI, so a single word such as testdev is rejected | NameID format | urn:oasis:names:tc:SAML:2.0:nameid-format:persistent | Email claim | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress Microsoft recommends the tenant-specific audience for new federations. Existing federations that use the global urn:federation:MicrosoftOnline value keep working, but a new federation stops working if the IdP expects the global issuer URL. If the partner uses WS-Fed, Microsoft has only tested AD FS and Shibboleth. ## Set it up You'll need the External Identity Provider Administrator role or higher. - In the Microsoft Entra admin center, go to Entra ID > External Identities > All identity providers. - On the Custom tab, select Add new > SAML/WS-Fed. - Enter a display name, choose SAML, and tick Domainless. - Either parse the partner's metadata file, or enter the Issuer URI, passive authentication endpoint (HTTPS only) and signing certificate by hand. Add the Metadata URL too: with it, Entra can renew the signing certificate automatically. Without it, you'll have to update the certificate yourself whenever it changes. - Save, then wait 5 to 10 minutes before anyone tries to redeem an invitation. - Under Cross-tenant access settings, open the redemption order and move SAML/WS-Fed identity providers to the top of the primary identity providers list, so the federated IdP is tried first. To switch an existing domain-based IdP over, open its domains pane, tick Domainless and select Done. ### Invite the guest Invite them as normal (Users > All users > New user > Invite external user). Their email doesn't need to match any domain. The important part is the redirect URL: add a domain_hint whose value matches the Issuer URI on your IdP configuration exactly. Copy it straight from the configuration in the admin center rather than typing it. ## Limits to know about - One domainless IdP per tenant. Microsoft's documentation says only one wildcard IdP can be configured per tenant, so choose the partner that needs it most. Others stay on domain-based federation. - Known issue: if you type an invalid domain name into an IdP configuration, the configuration can be deleted, even if you hadn't saved it. Double-check before you add domains. - Removing federation locks guests out. Guests who already redeemed can't sign in once the configuration is deleted. You'll need to reset their redemption status to give them access again. ## Checklist - Partner IdP sends a persistent NameID and the emailaddress claim - Audience set to your tenant-specific endpoint - Domainless ticked, and the metadata URL added so certificates renew - SAML/WS-Fed moved to the top of the redemption order - Invitations sent with domain_hint set to the exact Issuer URI - Test with one guest before inviting the rest **Does this replace domain-based federation?** No. Domain-based federation still works, and since you can only have one domainless IdP, most tenants will run both: domainless for the partner with mixed email domains, domain-based for the rest. **Can I configure it with Graph instead of the portal?** Yes. Federation is managed through the samlOrWsFedExternalDomainFederation resource, which is documented in the Microsoft Graph beta reference. **What about the partner's signing certificate expiring?** The IdP list shows each certificate's expiry date. With a metadata URL, Entra renews it for you. If the partner rotates early, or you didn't add a URL, edit the configuration and enter the new certificate. Sources - Microsoft Learn: Add federation with SAML/WS-Fed identity providers (https://learn.microsoft.com/en-us/entra/external-id/direct-federation) - Microsoft Learn: What's new in Microsoft Entra (https://learn.microsoft.com/en-us/entra/fundamentals/whats-new) --- # How a Tube gate gets paid: half a second at the edge, the maths in the back office URL: https://azureblog.co.uk/posts/how-a-tube-gate-gets-paid/ Published: 2026-10-10 Tags: Azure > You tap a bank card, the gate opens, and your bank hasn't approved anything yet. Here's how London's contactless system works, why it's built that way, and the cloud design lesson inside it. Tap a contactless card on a Tube gate and the paddles open almost straight away. Your bank hasn't approved a payment at that point, and nobody has worked out your fare yet. Charging you is something that happens later. It's one of the best real-world examples of a pattern every cloud architect uses: make a fast decision at the edge with the data you have locally, then settle the details in the back end. This post walks through the whole process, from the tap to your bank statement. Watch the video first, or skip straight to the detail below. ## The half-second budget A ticket gate exists to move people. When TfL brought bank cards to the gates, the time a reader could spend on each transaction was capped at 500 milliseconds, roughly the time it takes to walk through without breaking stride. Mastercard's case study on the rollout puts the average entry validation at about 300 milliseconds. Asking a card issuer to authorise a payment can't reliably fit into that window. Add peak-time crowds at a busy station, and a gate that waited for the bank would turn into a queue on the street. ## What the gate checks on its own So the gate doesn't ask. The yellow reader carries out EMV cryptographic authentication with the card entirely offline, with no key or data exchange with remote servers. The card proves it's a genuine card, which stops cloned or counterfeit cards, without a round trip to anyone. The second check is about debt. TfL's conditions of use say you aren't allowed to travel on a contactless card that has unpaid fares against it until the amount is paid in full. If the card is genuine and doesn't owe anything, the paddles open. [Diagram: What happens on the day, and what happens afterwards.] ## The back office does the real work Every tap, in and out, goes to TfL's back office, which handles fare calculation, capping and the online account. Three things happen there. ### 1. Taps become journeys A tap in at Brixton and a tap out at Oxford Circus become one Victoria line journey. That's why touching in and out matters on the Tube, DLR, Overground, Elizabeth line and National Rail. On buses and trams you only touch in. If you don't touch in and out correctly, you may be charged a maximum fare. Take longer than the time limit between touching in and out, and the conditions say you can be charged two maximum fares. ### 2. Capping Once your journeys are known, the system applies daily capping, and weekly capping from Monday to Sunday. You only get capping if you use the same card or device for every journey in that period. A few services, such as the London Cable Car, Thames Clippers River Buses, Heathrow Express, Gatwick Express and Southeastern high speed services, don't count towards it. ### 3. One charge TfL charges your card after you've finished travelling for the day. The bank statement shows one TfL Travel charge for the day, not one per tap, and Barclays says it usually appears within three days. A small detail that surprises people: in some zones the daily cap is over £100. The charge is the day's total, so it can be larger than the £100 limit you'd hit if you tapped to pay in a shop. | When | Where | What happens | At the gate | Yellow reader, offline | Card authenticated, unpaid-fare check, paddles open in about 0.3 seconds | During the day | TfL back office | Taps collected from every gate and reader | After the day's travel | TfL back office | Taps paired into journeys, maximum fares and caps applied, one charge sent to your bank | Within a few days | Your bank | A single TfL Travel entry on your statement ## When the bank says no Because you travel first and pay later, some payments will be declined. TfL's conditions spell out what happens next: - TfL tries again, but not more than three times, no more than once a day, and only within 30 days of the decline. On a statement, these show up as unpaid fares. - It also tries to collect the unpaid amount the next time you touch the card on a yellow reader. - Until the debt is paid in full, you can't travel on that card. You can pay through your TfL online account or by calling TfL. That last rule is what makes the offline check work. The gate doesn't need to know whether today's journey will be paid for. It only needs to know whether this card already owes money. ## TfL did the maths Letting people through before they've paid means some fares will be lost. The alternative is making millions of people wait at the gates every day. The numbers suggest it was worth it: Mastercard's case study reports that TfL's cost of collecting fares fell from around 14 percent of revenue to just below 9 percent, with a target of about 6 percent. [Diagram: The design choice behind the gates.] ## How big it is - Contactless bank cards were accepted on London buses from December 2012, and on the whole network from September 2014. - By early 2017, contactless was handling about 1.8 million journeys a day, from cards and devices issued in more than 100 countries. - Cubic, which runs TfL's revenue collection system, lists 2,808 gates and around 10,000 Oyster readers, and says more than five billion journeys have been made by over 40 million unique cards and devices. ## Where Microsoft and Azure come in A couple of public examples link TfL to Microsoft, with one caveat: they're from about a decade ago, so the current setup may well be different. - Live Tube data on Azure. TfL moved its Trackernet feed, which publishes real-time train locations and line status to developers, to what was then Windows Azure. It was built to handle more than seven million requests a day. Feeds like this are what travel apps use. - Contactless billing on SQL Server. In 2015, Microsoft said the data behind TfL's contactless system was held centrally on Microsoft SQL Server. Unlike Oyster, where much of the data sits on the card, contactless keeps the account data in the back office. ## The lesson for cloud architects Strip away the paddles and the pattern is one you'll recognise: - Decide at the edge with local data. The gate never waits on a far-away system. The same is true when an API validates an Entra access token by checking its signature locally rather than calling Entra on every request. You can see what's inside a token with the JWT decoder (https://azureblog.co.uk/tools/jwt/). - Keep a short list of what's not allowed. The gate refuses cards that owe money. In identity, continuous access evaluation (https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation) plays a similar role, letting services react quickly to critical events such as a disabled account instead of waiting for a token to expire. - Reconcile centrally, later. Journeys, caps and charges are worked out once there's a full picture. That's eventual consistency, chosen on purpose. - Put a number on the risk. A small, bounded loss is acceptable when the gain in speed and cost is this large, and the retry and block rules keep the loss bounded. **Why do I only see one TfL charge a day?** TfL adds up all your journeys for the day, applies any cap, and then charges your card once for the total. **Can the charge be more than £100?** Yes. Some daily caps are above £100, and because the charge is made after you travel, it isn't limited in the same way as a single tap-to-pay in a shop. **What if I use two different cards?** Capping only works when you use the same card or device for every journey in the day or week. Watch out for card clash: if you touch a wallet with more than one card in it, the reader may pick the wrong one. **Is this exactly how TfL built it?** This explains the process using TfL's published conditions of use and public case studies. TfL's internal design isn't public, so the detail inside the back office is described at the level those sources give. Sources - TfL: Contactless cards and devices conditions of use (https://content.tfl.gov.uk/tfl-contactless-cards-and-devices-conditions-of-use.pdf) - Mastercard: Transport for London case study (April 2017) (https://www.mastercard.us/content/dam/mccom/en-us/documents/transport-for-london-case-study-april-2017.pdf) - Cubic: Transport for London case study (https://go.cubic.com/hubfs/CTS%20Collateral/CTS/Case%20Studies/Cubic%20Transportation%20Systems%20Transport%20for%20London%20Case%20Study.pdf) - Barclays: How a contactless payment to TfL appears on your account (https://www.barclays.co.uk/help/cards/contactless/when-charged/) - Microsoft Azure blog: Transport for London moves to Windows Azure (https://azure.microsoft.com/de-de/blog/?p=13352) - Microsoft UK Stories: Six months of contactless journeys on London's transport network (https://ukstories.microsoft.com/?p=13623) - Microsoft Learn: Continuous access evaluation (https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation) --- # SOC Identity Responder: contain a compromised account without handing out admin roles URL: https://azureblog.co.uk/posts/entra-soc-identity-responder-role/ Published: 2026-10-09 Tags: Entra ID, Security, Governance, What's new > A new built-in Entra role lets security analysts disable users, revoke sessions and reset passwords from Microsoft Defender, and nothing else. Here's what it can and can't do, and how to set it up with PIM. When an account is compromised, the first few minutes matter. The attacker has a session and possibly a password, and the analyst who spotted it in Microsoft Defender needs to cut them off. In many organisations that analyst can't. Either they wait for someone on the identity team, or they've been given broad roles such as User Administrator or Helpdesk Administrator "just in case", which lets them change far more than they need to. Microsoft has added a built-in role for exactly this job: Entra SOC Identity Responder, in public preview. It holds four permissions, all about containment, and it can only act on users who don't hold admin roles. ## What the role can do | Permission | What it lets the analyst do | microsoft.directory/users/disable | Disable an account, so it can't sign in | microsoft.directory/users/enable | Re-enable it once the incident is closed | microsoft.directory/users/invalidateAllRefreshTokens | Revoke sign-in sessions, forcing the user (or attacker) to sign in again | microsoft.directory/users/password/update | Reset the password Microsoft describes it as a role for containment actions taken from the Microsoft Defender portal. The actions are still enforced and audited by Entra, so they show up in the audit log like any other change. The role's template ID is 58f930cc-fcf4-4152-852c-1d7dbf502139, which you can look up with the GUID lookup (https://azureblog.co.uk/tools/guid/). [Diagram: What analysts typically held before, and what this role gives them instead.] ## What it can't do The limits are as useful as the permissions, because they tell you where the identity team still has to step in. - No admin accounts. Like Security Administrator and Security Operator, the role is limited to non-administrative users and can't act on privileged accounts. A compromised admin still needs a Privileged Authentication Administrator or Global Administrator. - No authentication methods. It can't see or remove a user's MFA methods. If the attacker registered their own Authenticator or phone number, someone with Authentication Administrator has to remove it. - No devices, groups or apps. Disabling a device, removing group memberships or revoking app consent are separate jobs for other roles. One detail worth knowing: Microsoft notes that the ability to reset a password includes updating the phone and alternative email properties that self-service password reset uses. That's another reason to treat it as a privileged role, which Microsoft labels it as. ## How containment fits together [Diagram: A typical containment flow with the role made eligible through PIM.] Order matters. Disable the account first so no new sign-ins succeed, then revoke sessions so existing refresh tokens stop working, then reset the password before you re-enable anything. Revoking sessions doesn't instantly kill access tokens that have already been issued. They run until they expire, unless the app supports continuous access evaluation, so a disabled account plus revoked sessions is the combination you want. ## Setting it up properly The role supports role-assignable groups and works with PIM, so a sensible design is an eligible assignment to a group that holds your SOC analysts. - Create a role-assignable security group, for example ROLE-SOC-Identity-Responders. Only Global Administrators, Privileged Role Administrators and the group's owners can manage its membership, which protects it from tampering. Don't give the SOC analysts ownership of it. - Make the group eligible for Entra SOC Identity Responder in PIM, rather than permanently active. - Set activation rules: a short maximum duration, a justification, and ideally an authentication context that requires phishing-resistant MFA (https://azureblog.co.uk/posts/pim-activation-conditional-access-context/). Skip approval, because waiting on an approver defeats the point of a fast containment role. - Remove the old roles analysts were holding for containment, once the new one is tested. ``` Connect-MgGraph -Scopes "Group.ReadWrite.All","RoleManagement.ReadWrite.Directory" # Role-assignable group for the SOC $group = New-MgGroup -DisplayName "ROLE-SOC-Identity-Responders" -MailEnabled:$false ` -MailNickname "role-soc-identity-responders" -SecurityEnabled -IsAssignableToRole:$true # Make the group eligible for the role for a year New-MgRoleManagementDirectoryRoleEligibilityScheduleRequest -BodyParameter @{ Action = "adminAssign" PrincipalId = $group.Id RoleDefinitionId = "58f930cc-fcf4-4152-852c-1d7dbf502139" # Entra SOC Identity Responder DirectoryScopeId = "/" Justification = "SOC containment role" ScheduleInfo = @{ StartDateTime = Get-Date; Expiration = @{ Type = "AfterDuration"; Duration = "P365D" } } } ``` Analysts then activate it in the portal, or from PowerShell as described in activating PIM roles with Microsoft Graph (https://azureblog.co.uk/posts/activate-pim-roles-with-powershell/). ## Containment from PowerShell The Defender portal is the intended place to take these actions, but it's useful to have a fallback. With the role active, an analyst can do the same from Microsoft Graph PowerShell: ``` Connect-MgGraph -Scopes "User.EnableDisableAccount.All","User.RevokeSessions.All" $upn = "jane.doe@contoso.com" Update-MgUser -UserId $upn -AccountEnabled:$false # 1. stop new sign-ins Revoke-MgUserSignInSession -UserId $upn # 2. invalidate refresh tokens ``` Afterwards, the user sees AADSTS50057 (https://azureblog.co.uk/errors/aadsts50057/) (account disabled) if they try to sign in. To see what the attacker did before you stepped in, paste their sign-ins into the sign-in log explainer (https://azureblog.co.uk/tools/signin/) or use the queries in the KQL library (https://azureblog.co.uk/tools/kql/). ## Things to check before relying on it - It's in public preview, so test it in your tenant before writing it into the incident runbook - For users synced from Active Directory, check how disabling and password resets behave in your setup: attributes mastered on-premises and password writeback both affect the result - Agree a handover with the identity team for what the role can't do: MFA methods, admin accounts, devices and app consent - Alert on activations of the role, the same way you'd alert on other privileged roles - Include the group in your regular access reviews **Is this the same as Security Operator?** No. Security Operator is about managing security events and settings in security tools. SOC Identity Responder is narrowly about directory actions on user accounts: disable, enable, revoke sessions and reset password. Both are limited to non-administrative users for these actions. **Can the role unlock an account locked by Smart Lockout?** No. Smart Lockout clears on its own. The role is for disabling and resetting, not unlocking. **Does it need extra licences?** Microsoft's announcement doesn't list a licence for the role itself. Using PIM for just-in-time activation needs Entra ID P2 or Entra ID Governance, as usual. Sources - Microsoft Learn: What's new in Microsoft Entra (https://learn.microsoft.com/en-us/entra/fundamentals/whats-new) - Microsoft Learn: Entra built-in roles, Entra SOC Identity Responder (https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#entra-soc-identity-responder) - Microsoft Learn: Privileged roles and permissions, who can reset passwords (https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/privileged-roles-permissions#who-can-reset-passwords) --- # Road to 50: how this blog runs for about £1 a month URL: https://azureblog.co.uk/posts/road-to-50-running-this-blog-for-1-a-month/ Published: 2026-10-08 Tags: Azure > Fifty posts in, here's exactly how azureblog.co.uk is built, hosted and published, and why the whole thing costs less than a coffee each month. This is post number fifty. It felt like the right moment to open up the bonnet and show how the site itself works, because it's a neat example of how far the free and near-free tiers in Azure can take you. ## The bill | Service | What it does | Monthly cost | Static Web Apps (Free) | Hosts the site on a global edge network, with free managed SSL certificates and custom domains | £0 | Azure DNS | Hosts the DNS zone for the domain | about 40p, plus a few pence per million queries | GitHub | Stores the source and runs the build and deployment workflow | £0 The domain registration is the only other cost, and that's paid yearly to the registrar. Everything else rounds to well under £1 a month. ## The architecture There's no server, database or CMS. A small Node.js script turns a folder of posts into plain HTML files, and Static Web Apps serves them. [Diagram: Each layer only does one job.] - Static Web Apps serves the files from the edge. A small staticwebapp.config.json sets security headers, cache rules and the 404 page. - Azure DNS handles both the bare domain and www. Bare domains can't use a CNAME, and many registrars don't offer ALIAS records, so moving the zone into Azure DNS was the clean fix. The domain stays registered where it was; only the nameservers changed. - GitHub Actions runs the build and deploys the output with the official Azure/static-web-apps-deploy action. ## What the build does Each post is a single HTML file with a small block of metadata at the top: title, date, tags and a one-line summary. The build script reads them all and produces: - a page for every post, tag and tool, with reading time worked out from the word count - a social sharing image for every post, drawn as SVG and rendered to PNG - the RSS feed, sitemap and a search index - a calendar feed of Microsoft deadlines from the timeline (https://azureblog.co.uk/timeline/) - the diagrams in posts, which are written as a few lines of JSON and turned into HTML and SVG at build time The tools (https://azureblog.co.uk/tools/) run entirely in your browser. The JWT and SAML decoders, the GUID lookup and the rest load a JSON file and do the work locally, so nothing you paste is sent anywhere. ## How a post gets published [Diagram: From commit to live in about a minute.] The workflow also runs once a day on a schedule, so anything date-based, like the countdowns on the timeline, stays current without a commit. No plugins to patch, no hosting control panel, no database backups. Git history is the backup, and rolling back a mistake is a revert. ## What I'd tell anyone starting a technical blog - Start simpler than you think. A static site is fast, secure and nearly free. Add a build step only when you have a reason to. - Write the post you wish you'd found. Most of the posts here started as an error message or a change notice that needed a clear explanation. - Link to the source. Microsoft changes things often. Every news post here links to the official documentation so readers can check the latest detail. - Use your own platform. Hosting an Azure blog on Azure keeps the skills sharp and gives you real-world material to write about. ## Next fifty More of the same: what's changing in Entra ID, Intune and Azure, what it means in practice, and the scripts and steps to act on it. Thanks for reading. --- # Intune in September: deployment rings, faster compliance and stricter automation URL: https://azureblog.co.uk/posts/intune-september-2026-roundup/ Published: 2026-10-06 Tags: Intune, Windows, What's new > Five recent Intune changes that affect how you roll out, how quickly devices become compliant, and whether your automation keeps working. ## Deployment plans: proper rings, built in The new Deployments experience lets you stage a rollout across multiple rings with controlled timing, instead of assigning straight to everyone or juggling pilot groups by hand. It works with Win32 apps, Enterprise App Catalog apps, Settings Catalog policies and endpoint security policies, and integrates with Multiple Admin Approval. For anything risky, such as a new security baseline or a firewall policy change, this should become the default way you deploy. [Diagram: A typical ring plan for a security baseline.] ## Client-driven compliance evaluation (preview) Compliance on Windows has traditionally waited for the next check-in. Now supported Windows devices notice when a compliance signal changes, such as the firewall, antivirus, BitLocker, Defender status, OS build, real-time protection or Secure Boot, and ask Intune to re-evaluate straight away. The practical benefit is speed. When a user fixes the problem that blocked them, they get access back faster. When a device falls out of compliance, Conditional Access catches it sooner. [Diagram: Scheduled versus client-driven compliance.] ## Multi Admin Approval now covers Graph automation Multi Admin Approval (MAA) used to apply only to changes made in the admin center. It now applies to Microsoft Graph calls too. If you have MAA access policies protecting a resource, scripts and apps that change it without going through approval now get an HTTP 403 error. - Check which automation touches MAA-protected resources, such as app deployments or scripts. - Update those scripts to follow the MAA approval workflow. - If you can't change an app yet, use the new Exclusions tab in the access policy to exempt it. Treat that as temporary. [Diagram: An automation call against a protected resource.] ## Windows 11 26H2 security baseline A new security baseline for Windows 11, version 26H2, is available. Existing baseline profiles don't update automatically. Create a new profile or update the version on an existing one, and compare the setting changes first. Deployment plans are a sensible way to roll it out. ## iOS/iPadOS 18 is now the minimum Intune now requires iOS/iPadOS 18 or later for standard device management, Company Portal and app protection policies. Check your device inventory for older devices before users run into problems. ## Checklist - Plan a deployment plan for the next baseline or major policy change - Pilot client-driven compliance on a few Windows devices - Find scripts and apps that change MAA-protected resources - Create a new 26H2 baseline profile and compare settings - Report on iOS devices below version 18 Sources - Microsoft Learn: What's new in Microsoft Intune (https://learn.microsoft.com/en-us/intune/whats-new/) - Microsoft Learn: Deployment plans and deployments (https://learn.microsoft.com/en-us/intune/device-management/deployments/overview) - Microsoft Learn: Multi Admin Approval with the Graph API (https://learn.microsoft.com/en-us/intune/fundamentals/role-based-access-control/multi-admin-approval-graph-api) --- # Lock down app consent without blocking your users URL: https://azureblog.co.uk/posts/admin-consent-workflow-and-user-consent/ Published: 2026-09-23 Tags: Entra ID, Security, Governance > Illicit consent grants are a favourite way to steal mailbox data. Restricting user consent and turning on the admin consent workflow closes the door without making life miserable. When a user signs in to a third-party app for the first time, the app can ask for permissions to their data, such as reading their mail or files. If users can grant any permission, an attacker only needs a convincing app and a phishing email. The resulting access survives password resets, because it isn't based on the password. [Diagram: How an illicit consent grant works, and why restricting consent stops it.] ## 1. Restrict user consent In the Entra admin center, go to Enterprise applications → Consent and permissions → User consent settings. Choose: - Allow user consent for apps from verified publishers, for selected permissions, and - under Permission classifications, mark only low-risk permissions (such as User.Read, openid, profile, email and offline_access) as low impact. Users can still sign in to well-known apps that only need basic profile access. Anything riskier needs an admin. ## 2. Turn on the admin consent workflow Under Enterprise applications → Admin consent settings, enable Users can request admin consent to apps they are unable to consent to, and choose reviewers. Instead of a dead end, users see a request form, and reviewers get an email with the app and the permissions requested. [Diagram: With the workflow on, users ask instead of being blocked.] ## 3. Review what's already granted Existing consents aren't affected by the new settings. Review the apps with risky delegated permissions such as Mail.Read, Files.ReadWrite.All or anything granted to all users: ``` Connect-MgGraph -Scopes "Directory.Read.All" Get-MgOauth2PermissionGrant -All | Where-Object { $_.Scope -match "Mail\.|Files\.|Sites\.|Directory\." } | ForEach-Object { [pscustomobject]@{ App = (Get-MgServicePrincipal -ServicePrincipalId $_.ClientId).DisplayName ConsentType = $_.ConsentType Scope = $_.Scope } } | Sort-Object App | Format-Table -AutoSize ``` Revoke anything you don't recognise, and investigate how it got there. Reviewer tip: before approving, check the publisher is verified, the permissions match what the app actually does, and someone in the business owns the request. ## What reviewers should check - Is the publisher verified, and is it the company you expect? - Do the requested permissions match what the app does? - Is this a delegated or application permission? - Who in the business owns the request, and is there a contract? - Is there a narrower permission available? The Graph permission explainer (https://azureblog.co.uk/tools/permissions/) shows what each permission allows and suggests narrower alternatives. ## If you find a malicious grant - Remove the app's permissions and disable sign-in for the Enterprise App. - Revoke the affected users' sessions. - Check the audit log for when consent was granted and by whom. - Check what the app accessed, using the mailbox and SharePoint audit logs. --- # Unattended Graph PowerShell scripts with certificate authentication URL: https://azureblog.co.uk/posts/graph-powershell-app-only-certificate/ Published: 2026-09-16 Tags: PowerShell, Entra ID, Security > Scheduled scripts can't answer an MFA prompt. App-only authentication with a certificate is the right way to run Microsoft Graph PowerShell unattended. Interactive Connect-MgGraph is fine at your desk. A scheduled task or server-side script needs its own identity. If the script runs in Azure, use a managed identity. Otherwise, use an app registration with a certificate, never a client secret pasted into the script. [Diagram: Interactive versus app-only sign-in.] ## 1. Create a certificate For a script on a Windows server, a self-signed certificate in the machine store works well: ``` $cert = New-SelfSignedCertificate -Subject "CN=Graph-UserReport" ` -CertStoreLocation "Cert:\LocalMachine\My" ` -KeyExportPolicy NonExportable -KeySpec Signature ` -NotAfter (Get-Date).AddYears(1) Export-Certificate -Cert $cert -FilePath C:\Temp\Graph-UserReport.cer ``` Only the public key (.cer) leaves the server. The private key stays put and can't be exported. ## 2. Register the app - Create an app registration, single tenant. - Under Certificates & secrets, upload the .cer file. - Under API permissions, add the Application permissions the script needs, such as User.Read.All, and grant admin consent. Keep it to the minimum. - Add at least two owners. ## 3. Connect in the script ``` Connect-MgGraph -ClientId "" -TenantId "" ` -CertificateThumbprint "" -NoWelcome Get-MgUser -All -Property DisplayName,UserPrincipalName,AccountEnabled | Export-Csv C:\Reports\users.csv -NoTypeInformation ``` [Diagram: What happens when the script connects.] ## Keep it safe - Run the scheduled task as an account that can read the certificate's private key, and no more. - Track the certificate's expiry date and renew it before it lapses. - Watch the app's sign-ins in the service principal sign-in logs. - Consider limiting the app with a Conditional Access policy for workload identities if you have the licensing. ## Renewing the certificate - About a month before expiry, create a new certificate on the server, as before. - Upload the new .cer to the app registration. Both certificates now work. - Update the thumbprint in the script, or the scheduled task's parameter, and test a run. - Remove the old certificate from the app registration and the server. ## Troubleshooting - AADSTS700027 (client assertion failed signature validation): the certificate on the server doesn't match one uploaded to the app, or it has expired. - Certificate not found: the account running the task can't see it. Check the store (LocalMachine or CurrentUser) and the private key permissions. - 403 Forbidden from Graph: the app is missing an application permission, or admin consent wasn't granted. --- # Microsoft is retiring its own SMS and voice MFA. Here's your plan. URL: https://azureblog.co.uk/posts/entra-sms-voice-mfa-retirement/ Published: 2026-09-04 Tags: Entra ID, Security, Passkeys, What's new > Microsoft-provided text and phone call authentication in Entra ID ends for most users on 1 February 2027. Passkeys are already being switched on. What changes, when, and what to do now. This is the biggest authentication change in Entra ID for years. Microsoft is retiring the SMS and voice call authentication it delivers itself, and is pushing users towards passkeys instead. If any of your users still verify with a text message or a phone call, this affects you. ## What's actually retiring The change covers Microsoft-provided SMS and voice: the codes and calls Microsoft's own telephony service sends. It applies to SMS and voice in the Authentication Methods Policy, to the legacy MFA settings, and across Entra including self-service password reset. Two things are not retiring. External MFA methods are unaffected. And organisations that genuinely need SMS or voice can keep it by contracting with a third-party telephony provider through the Microsoft Security Store. The scope is the public cloud. Government clouds follow later, Azure AD B2C is out of scope, and External ID is getting its own announcement. ## The timeline | Date | What happens | 1 Sep 2026 | Passkeys are switched on automatically for users enabled for SMS or voice. A Microsoft-managed registration campaign nudges them to register a passkey at their next MFA sign-in. They can snooze it. | 30 Oct 2026 | Third-party telephony providers become configurable in the Microsoft Security Store. | 1 Feb 2027 | Retirement for all users except Global Administrators and external users. Anyone whose only method is SMS or voice gets a blocking prompt to register a passkey. | 1 Jul 2027 | Retirement for Global Administrators and external users. Users won't be locked out. Anyone still relying only on SMS or voice gets a registration prompt they can't skip, and must set up a passkey before carrying on. For a busy service desk, that's still a Monday morning you want to avoid. [Diagram: Key dates from Microsoft's SMS and voice retirement FAQ.] ## What to do now - Measure your exposure. Microsoft publishes an entra-sms-voice-usage-analyzer PowerShell script on GitHub. It reports which users are in scope of SMS and voice in your authentication methods policies. Any non-zero result means your tenant is affected. - Decide passkeys or provider. Without a regulatory or operational reason to keep SMS, plan for passkeys. If you do need SMS, line up a telephony provider and move users before their retirement date. - Plan your passkey rollout. Use passkey profiles to set different rules for admins and standard users, and decide whether synced passkeys (stored in a passkey provider and shared across devices) are acceptable for each group. - Use the registration campaign. It now supports passkeys, so users are prompted at sign-in rather than chased by email. - Don't forget the edges. Shared mailboxes with MFA, break-glass accounts, frontline workers without smartphones and guests all need a plan. ## Who is affected, in practice The users who feel this most are the ones who have only SMS or voice registered. Anyone who already has Microsoft Authenticator, a passkey or Windows Hello for Business simply carries on with those. So the real work is finding the SMS-only group and moving them before the deadline. [Diagram: Which path each user takes.] Typical SMS-only groups are frontline staff without company phones, people who joined before Authenticator was standard, and shared or service-style accounts that someone set up with a phone number years ago. ## A rollout plan that works - Weeks 1 to 2: measure. Run the analyzer script, then export the authentication methods registration report to get a named list of SMS-only users. - Weeks 2 to 3: decide the exceptions. Agree how you'll handle users with no smartphone: a FIDO2 security key, Windows Hello for Business on a managed PC, or a third-party SMS provider. - Weeks 3 to 4: communicate. Tell users what a passkey is and what the prompt will look like, before they see it. - Weeks 4 to 8: campaign. Let the registration campaign prompt people at sign-in. Limit snoozes once most users have registered. - Ongoing: chase the tail. Contact the remaining SMS-only users directly, and issue Temporary Access Passes where people are stuck. Ready-made emails: the user comms templates (https://azureblog.co.uk/tools/comms/) include "Moving to passkeys" and "Text message codes are going away". ## Need more time? There's a temporary opt-out that delays the automatic passkey enablement and registration campaign until 1 February 2027, while you set up a provider or migrate users. It's set through Graph: ``` PATCH https://graph.microsoft.com/beta/policies/authenticationmethodspolicy Content-Type: application/json { "optOutSettings": { "passkeyDynamicMigration": true } } ``` Important: the opt-out only delays the rollout. It does not stop enforcement. From 1 February 2027 the retirement applies regardless. ## Questions people ask **Will users be locked out on 1 February 2027?** No. Users who still rely only on Microsoft-provided SMS or voice get a blocking prompt to register a passkey and can carry on once they have. **Is SMS still allowed for self-service password reset?** Microsoft's FAQ says the retirement applies across Entra, including SSPR. Organisations that need SMS can use a telephony provider from the Microsoft Security Store. **Does this affect external MFA providers?** No. External MFA methods aren't affected, unless the same users are also enabled for Microsoft's SMS or voice. **Does the opt-out stop the retirement?** No. It only delays automatic passkey enablement and the registration campaign until 1 February 2027. Sources - Microsoft Learn: SMS and voice retirement FAQ (https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement-faq) - GitHub: entra-sms-voice-usage-analyzer (https://github.com/microsoft/entra-sms-voice-usage-analyzer) - Microsoft Learn: Enable passkeys (FIDO2) in Entra ID (https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-passkeys-fido2) --- # Intune in August: unattended Remote Help, DDM app installs and eSIM URL: https://azureblog.co.uk/posts/intune-august-2026-roundup/ Published: 2026-09-02 Tags: Intune, What's new > Helpdesk agents can now support Windows devices with nobody at the keyboard, Apple VPP apps can install through declarative device management, and corporate Android gets eSIM control. ## Unattended Remote Help for Windows Remote Help on physical Windows devices now supports unattended sessions. Helpdesk agents sign in with their own credentials and connect without a user being present. It's ideal for kiosks, meeting room PCs and out-of-hours fixes. Lock it down with Remote Help roles and scope tags so only the right people can use it on the right devices. [Diagram: Attended and unattended sessions.] Because nobody approves an unattended session, permissions matter more. Use a dedicated Remote Help role, scope it with scope tags to the device groups that need it, and review the session reports regularly. ## Declarative device management for VPP apps Apple Volume Purchase Program apps can now install through declarative device management (DDM). Set the management type to DDM when you upload the VPP token. It requires iOS/iPadOS 17.2 or later, or macOS 26 or later. DDM lets devices act on their own state rather than waiting for commands, which tends to make installs faster and more reliable. [Diagram: Command-based versus declarative management.] ## eSIM management for corporate Android On corporate-owned Android devices, you can now activate eSIMs, remove individual eSIMs, and choose whether eSIMs are removed during a wipe. It requires Android 15 or later, or Android 17 for work profile devices, and uses the preview device view. ## Also new - Audit mode for Defender Antivirus on Linux, to detect threats without quarantining while you test. - Apple OS 27 settings in beta in the Settings Catalog, for testing ahead of release. - A security baseline for Windows 365 for Agents. ## What to do this month - Decide who may run unattended Remote Help, and set up roles and scope tags - Check your Apple devices meet the OS requirement before switching VPP tokens to DDM - Corporate Android: decide whether eSIMs should be removed on wipe - Test Apple OS 27 settings on beta devices only Sources - Microsoft Learn: What's new in Microsoft Intune (https://learn.microsoft.com/en-us/intune/whats-new/) --- # Stop surprise Azure bills with budgets and anomaly alerts URL: https://azureblog.co.uk/posts/azure-budgets-and-cost-anomaly-alerts/ Published: 2026-08-26 Tags: Azure, Governance > Azure won't stop you spending, but it will tell you early if you set it up. Two features take five minutes and catch most surprises. ## Budgets A budget tracks spending against an amount over a period and sends alerts when you cross thresholds. Create one in Cost Management → Budgets at subscription or resource group scope. [Diagram: How a budget alert reaches someone who can act on it.] - Set thresholds on actual cost (such as 50%, 80% and 100%) and on forecasted cost (such as 100%). Forecast alerts warn you before the money is spent. - Send alerts to a shared mailbox or an action group, not one person. - Budgets alert; they don't stop anything. Use an action group to trigger automation if you need it, for example shutting down dev VMs. ``` az consumption budget create \ --budget-name monthly-dev \ --amount 500 \ --category cost \ --time-grain monthly \ --start-date 2026-09-01 \ --end-date 2027-08-31 ``` ### Picking the thresholds [Diagram: A typical set of alerts across one month on a £500 budget.] The forecast alert is the most useful one. It arrives while there's still time to do something, rather than confirming the overspend after the fact. ### Scope and filters You can set budgets at management group, subscription or resource group scope, and filter them by tags, resource types or services. A filter on env = dev or a single expensive service gives a sharper alert than one big subscription number. ## Anomaly alerts Cost Management can detect unusual spending patterns in a subscription automatically. Turn on anomaly alerts under Cost alerts to get an email when spending jumps beyond the normal pattern, even if you're well under budget. A runaway log ingestion or a forgotten large VM shows up as an anomaly within a day or so, not at the end of the month. [Diagram: Budgets and anomaly alerts answer different questions.] Anomaly detection learns what normal looks like for a subscription, so a new subscription needs some history before it's useful. It's a good partner to budgets because the two fail in different ways: a budget that's set too high never fires, and anomaly detection doesn't care what the budget says. ## Make costs visible - Tag everything with an owner and a cost centre. Azure Policy can enforce and inherit tags. - Schedule a cost report by email to each team, grouped by their tag. - Review Advisor cost recommendations monthly for idle resources and right-sizing. ## Automating a response An action group can call a webhook, an Automation runbook, a Logic App or a Function. A common pattern for dev and test subscriptions: - Budget threshold at 100% of actual cost calls an action group. - The action group starts an Automation runbook with a managed identity. - The runbook deallocates VMs tagged autoshutdown = true and posts a message to the team. Keep automation to non-production. Stopping production workloads because of a cost alert is rarely the right trade. ## Five-minute checklist - A budget on every subscription, with a forecast alert at 100% - Alerts go to a shared mailbox or action group, not one person - Anomaly alerts switched on for each subscription - Owner and cost-centre tags enforced by Azure Policy - A monthly scheduled cost view emailed to each team - Advisor cost recommendations reviewed once a month **Will a budget stop Azure charging me?** No. Budgets only alert. Spending limits exist on some offer types, such as free and credit-based subscriptions, but pay-as-you-go and enterprise subscriptions keep running. **Why did my alert arrive late?** Cost data takes time to process, often several hours and sometimes up to a day. Budgets are an early warning, not a real-time meter. --- # Private endpoints and DNS: why your private endpoint isn't being used URL: https://azureblog.co.uk/posts/private-endpoints-dns/ Published: 2026-08-19 Tags: Azure, Security > You created a private endpoint, but traffic still goes to the public IP. It's almost always DNS. How private endpoint name resolution works and how to fix it. A private endpoint gives a PaaS service, such as a storage account, SQL database or Key Vault, a private IP address in your virtual network. Clients still connect using the normal public name, for example stdata.blob.core.windows.net. Whether they reach the private IP or the public one depends entirely on DNS. [Diagram: Resolving a storage account with a private endpoint from on-premises.] ## How it should resolve When a private endpoint exists, the public name becomes a CNAME to a privatelink name: ``` stdata.blob.core.windows.net → stdata.privatelink.blob.core.windows.net → 10.20.1.5 (inside your network) → public IP (everywhere else) ``` Your network needs to answer the privatelink name with the private IP. That's the job of a private DNS zone, such as privatelink.blob.core.windows.net. ## Inside Azure - Create the private DNS zone. Usually the private endpoint wizard does this for you. - Link it to every virtual network that needs to resolve it. In hub-and-spoke, link it to the hub, and make sure spokes use DNS that can resolve through the hub. - Keep one zone per service type, shared across the estate, rather than a new zone per endpoint. ### Common zone names | Service | Private DNS zone | Blob storage | privatelink.blob.core.windows.net | Azure Files | privatelink.file.core.windows.net | Key Vault | privatelink.vaultcore.azure.net | Azure SQL Database | privatelink.database.windows.net | App Service and Functions | privatelink.azurewebsites.net Each sub-resource gets its own zone. A storage account with blob and file endpoints needs records in two zones. ## From on-premises On-premises DNS servers can't query the Azure-provided resolver at 168.63.129.16 directly. That address only works from inside Azure. The usual fix: - Deploy an Azure DNS Private Resolver with an inbound endpoint in the hub. - On on-premises DNS, create conditional forwarders for the public service domains (such as blob.core.windows.net) pointing to the inbound endpoint's IP. ## Troubleshooting ``` nslookup stdata.blob.core.windows.net ``` Run it from the client that's failing. If you get a public IP back, DNS is the problem, not the private endpoint. Also check that the service's public network access setting matches your intent. Scale tip: in a landing zone, use Azure Policy to create the DNS records in the central private DNS zones automatically whenever a private endpoint is deployed. [Diagram: What nslookup tells you.] ``` # PowerShell equivalent, showing the CNAME chain Resolve-DnsName stdata.blob.core.windows.net | Format-Table Name, Type, IPAddress, NameHost ``` - Forward the public service domain, not the privatelink one, from on-premises - Avoid hosting privatelink zones on on-premises DNS: any account without a record there stops resolving - Custom DNS servers in Azure must forward to 168.63.129.16 - Link private zones to the VNet your DNS servers or resolver live in - Use Azure Policy to create DNS records when private endpoints are created --- # Key Vault: move from access policies to Azure RBAC URL: https://azureblog.co.uk/posts/key-vault-rbac-vs-access-policies/ Published: 2026-08-12 Tags: Azure, Security > Key Vault has two permission models. Azure RBAC is the recommended one, and switching is simpler than it looks if you plan the role mapping first. Key Vault can control data access with vault access policies (the original model) or Azure RBAC. Microsoft recommends RBAC, and there are good reasons. [Diagram: The two permission models for Key Vault data.] ## Why RBAC is better - One model everywhere. Permissions are managed the same way as every other Azure resource, and they appear in the same reviews and reports. - PIM support. Data-plane roles can be made eligible and time-boxed. - Finer scope. Roles can be assigned on a single secret, key or certificate, not just the whole vault. - Separation of duties. With access policies, anyone who can manage the vault can grant themselves access to its secrets. With RBAC, data access needs a role assignment permission they may not have. ## Common role mappings | Role | Use for | Key Vault Secrets User | Apps that read secrets | Key Vault Crypto User | Apps that use keys to encrypt, decrypt, sign or verify | Key Vault Certificate User | Apps that read certificates | Key Vault Secrets Officer | People who manage secrets | Key Vault Administrator | Full data-plane management. Use sparingly, ideally through PIM. [Diagram: Which role does this identity need?] ## Switching over - List the existing access policies and map each to an RBAC role. - Create the role assignments before switching. Role assignments can take a few minutes to take effect. - Switch the permission model: ``` az keyvault update --name kv-app-prod --resource-group rg-app --enable-rbac-authorization true ``` - Test every app that uses the vault. If something breaks, switching back restores the old access policies. Note: changing the permission model is itself a sensitive operation. Restrict who can do it, and treat it as a change, not a tweak. ## Finding vaults still on access policies ``` // Azure Resource Graph resources | where type == "microsoft.keyvault/vaults" | extend rbac = tobool(properties.enableRbacAuthorization) | where rbac != true | project name, resourceGroup, subscriptionId ``` Pair this with the built-in Azure Policy that audits Key Vaults not using RBAC, so new vaults don't add to the list. - Map every access policy to a role - Create role assignments and wait for them to apply - Switch the permission model - Test each app and pipeline - Remove leftover Contributor rights that were only there for access policies **Does switching delete the access policies?** They're kept but ignored while RBAC is on. Switching back makes them active again, which is your rollback. **Who can make the switch?** Changing the permission model needs permission to create role assignments, such as Owner or User Access Administrator, because it changes who can reach the data. --- # Intune in July: macOS custom compliance and Defender settings that finally win URL: https://azureblog.co.uk/posts/intune-july-2026-roundup/ Published: 2026-08-05 Tags: Intune, Security, What's new > Custom compliance comes to macOS, a preview stops Group Policy overriding your Defender settings, and Store app search goes regional. ## Custom compliance for macOS Custom compliance has been available for Windows and Linux: a script reports values and a JSON file defines the rules. It now comes to macOS. If you've been unable to express a Mac compliance requirement with the built-in settings, such as a specific agent running or a configuration file present, you now can. The pattern is the same on every platform: a script reports values as JSON, and a rules file states what's compliant. [Diagram: How custom compliance evaluates a device.] ## Controlled configuration for Defender Antivirus (preview) Defender Antivirus settings can come from Intune, Defender for Endpoint, Group Policy, Configuration Manager or local scripts, and conflicts are a classic headache. The new controlled configuration preview lets Intune or Defender for Endpoint settings take precedence over Group Policy, Configuration Manager and local scripts. For co-managed estates mid-migration, that's very welcome. [Diagram: Where Defender settings can come from, and which wins with controlled configuration.] ## Samsung Knox E-FOTA Intune can now manage firmware updates for corporate-owned Samsung devices with Knox E-FOTA, across dedicated, fully managed and work profile corporate-owned devices. ## Regional Microsoft Store search When adding Microsoft Store apps, you can now choose a market catalogue rather than only searching the US catalogue. Useful when an app is only published in certain regions. ## What to do this month - Mac fleets: list compliance requirements the built-in settings can't express, and pilot custom compliance - Co-managed fleets: test controlled configuration in a pilot to end Defender setting conflicts - Samsung corporate devices: decide whether to manage firmware updates with E-FOTA - Check your Store app search uses the right market catalogue Sources - Microsoft Learn: What's new in Microsoft Intune (https://learn.microsoft.com/en-us/intune/whats-new/) --- # Windows LAPS with Intune: unique local admin passwords in minutes URL: https://azureblog.co.uk/posts/windows-laps-with-intune/ Published: 2026-07-29 Tags: Intune, Windows, Security > If every PC shares the same local administrator password, one compromised machine means all of them. Windows LAPS fixes that, and it's built into Windows and Intune. A shared local admin password is a gift to attackers: compromise one device, extract the password hash, and move laterally to every other device with the same password. Windows LAPS gives every device its own random local admin password, rotates it automatically and backs it up to Entra ID. [Diagram: Before and after Windows LAPS.] ## 1. Enable LAPS in Entra In the Entra admin center, go to Devices → Device settings and set Enable Microsoft Entra Local Administrator Password Solution (LAPS) to Yes. Without this, devices can't back up their passwords. ## 2. Create the Intune policy In Intune, go to Endpoint security → Account protection and create a Local admin password solution (Windows LAPS) policy: - Backup directory: Backup the password to Azure AD only (Entra ID). - Password age: such as 30 days. - Password complexity and length: large letters, small letters, numbers and specials, at least 14 characters. - Post-authentication actions: reset the password, and optionally log off, after the password is used. This stops a retrieved password staying valid. If you've renamed the built-in Administrator account or use a custom one, set Administrator account name to match. ## 3. Retrieve a password In Intune, open the device and choose Local admin password. Retrievals are audited. Give the permission only to roles that need it, such as a custom role for the service desk. [Diagram: A service desk retrieval, start to finish.] ## 4. Rotate on demand Use the Rotate local admin password remote action after a password has been shared during a support call. Don't forget the legacy client: if devices still run the old Microsoft LAPS (the separate MSI), plan to remove it. Windows LAPS is built into supported Windows versions. ## Checking it's working - In Intune, the device's Local admin password page shows when the password was last rotated. - On the device, Event Viewer has a dedicated log at Applications and Services Logs → Microsoft → Windows → LAPS. - In PowerShell on the device, Get-LapsDiagnostics collects logs for troubleshooting. ## Common problems - No password shown: check the Entra device setting for LAPS is enabled. Without it, the backup is rejected. - Wrong account managed: if you renamed the built-in Administrator, set the account name in the policy. - Conflicts: remove old LAPS Group Policy settings or the legacy LAPS client to avoid two policies fighting. --- # Microsoft Authenticator now blocks jailbroken and rooted devices URL: https://azureblog.co.uk/posts/authenticator-jailbreak-root-detection/ Published: 2026-07-22 Tags: Entra ID, Security, What's new > Authenticator now refuses to add or use work and school accounts on jailbroken or rooted phones. There's nothing to configure, but your service desk should know. Jailbreak and root detection in Microsoft Authenticator is now generally available. On a jailbroken iPhone or rooted Android device, Authenticator blocks users from adding work or school accounts, and from using existing ones. [Diagram: What happens when a user opens Authenticator.] ## Why it matters A jailbroken or rooted phone has its platform protections removed. Malware on such a device can do much more, including interfering with the app that's supposed to prove who the user is. Blocking these devices protects the integrity of MFA and passkeys held in Authenticator. ## What you need to do - No configuration. It's enforced automatically and can't be switched off. - Brief the service desk. A user who suddenly can't use Authenticator may be on a modified device. The fix is a supported device or another method, not a workaround. - Check for single points of failure. Users whose only method is Authenticator on a blocked device can't complete MFA. A temporary access pass gets them going while they register something else. ## Why modified phones are risky Jailbreaking an iPhone or rooting an Android phone removes protections the platform relies on: app sandboxing, secure storage and checks that apps haven't been tampered with. On such a device, malware can read data from other apps, intercept what's on screen, or interfere with the app that proves who the user is. An authenticator on that phone can no longer be trusted to be what it says it is. ## Helping affected users - Confirm the issue: the user will see Authenticator refuse to add or use their work account. - Issue a Temporary Access Pass (https://azureblog.co.uk/posts/temporary-access-pass-onboarding/) so they can sign in and register a different method. - Offer an alternative: a supported phone, a FIDO2 security key, or Windows Hello for Business on their work PC. - If the user restores their phone to a supported state, they can set Authenticator up again. ## Check the bigger picture If you use Intune, device compliance policies can also mark jailbroken or rooted devices as not compliant, which blocks access through Conditional Access. Together, the two cover both the authenticator and the corporate apps. Sources - Microsoft Learn: What's new in Microsoft Entra (https://learn.microsoft.com/en-us/entra/fundamentals/whats-new) --- # BYOD Windows access with Entra registration is now GA URL: https://azureblog.co.uk/posts/byod-windows-entra-registration-ga/ Published: 2026-07-15 Tags: Entra ID, Windows, What's new > Users, partners and internal guests can now reach corporate resources from personal Windows devices using Entra registration, without joining them to anything. Personal Windows PCs have always been awkward. You don't want to join them to your directory, but users still need a supported way to reach email, Teams and web apps. Support for BYOD Windows devices using Entra registration is now generally available. It covers users, partners and internal guests. [Diagram: The three ways a Windows device relates to Entra ID.] ## Registered, not joined - Entra joined devices are corporate machines whose identity belongs to your organisation. - Entra registered devices are personal machines where the user adds a work account. The device gets an identity in your tenant, but the user keeps control of it. ## Controlling what personal devices can do Registration on its own isn't a security control. Pair it with Conditional Access: - Allow browser-only access to sensitive apps from unmanaged devices, using app-enforced restrictions in SharePoint and Exchange to block downloads. - Require phishing-resistant MFA from personal devices. - Use Intune app protection policies, or Edge for Business protections, to keep corporate data inside managed apps. Plan for offboarding: when someone leaves, revoke their sessions and remove the registered device. Personal devices don't come back to IT. ## A sensible policy set [Diagram: Access from a personal Windows device.] ## Registering a device - On the personal PC, open Settings → Accounts → Access work or school and select Connect. - Sign in with the work account and complete MFA. - The device appears in Entra under the user's devices as registered. Make sure users know they can remove the work account from the same screen, and that IT can't see their personal files. ## Questions users ask **Can IT see my personal files or browsing?** No. Registration gives the device an identity for sign-in. Without Intune enrolment, IT can't see or manage your files, apps or settings. **Can IT wipe my PC?** Not from registration alone. If app protection is used, IT can remove company data from managed apps, not your personal data. **How do I remove my work account?** Settings → Accounts → Access work or school, select the account and choose Disconnect. Putting these answers in your onboarding guide removes most of the hesitation users have about connecting a personal PC. Sources - Microsoft Learn: What's new in Microsoft Entra (https://learn.microsoft.com/en-us/entra/fundamentals/whats-new) --- # Entra Connect Sync is on its way out. Start planning for Cloud Sync. URL: https://azureblog.co.uk/posts/connect-sync-to-cloud-sync/ Published: 2026-07-08 Tags: Entra ID, Hybrid identity, What's new > Microsoft has started a phased move of identity sync from Entra Connect Sync to Cloud Sync, and has closed a privilege takeover route in hybrid sync. Here's what both changes mean for you. If you run hybrid identity, two changes this year deserve your attention. Microsoft is moving customers off Entra Connect Sync for identity synchronisation, and it has blocked a technique attackers could use to take over privileged cloud accounts through sync. ## The move to Cloud Sync Entra Cloud Sync replaces the heavy Connect Sync server with lightweight provisioning agents, with configuration held in the cloud. Microsoft is now transitioning customers to it in phases: - Notifications started in July 2026, through the Message Center, Connect Health and targeted emails. Each tenant gets its own timeline. - Simple tenants go first. Early waves target organisations whose needs Cloud Sync already covers. Large directories and those using advanced Connect Sync features come later, as Cloud Sync gains capabilities. - You can test first. Microsoft provides guidance and a transition tool, and you can move and test sync in Cloud Sync before anything permanent changes. - Hybrid authentication stays. Features that let on-premises credentials reach cloud resources remain available through the Connect Sync configuration wizard. Cloud Sync takes over the identity sync job. [Diagram: The two sync engines side by side.] ## Get ready before your notification lands - Inventory your current setup. List the custom sync rules, filtering, writeback options and other features you depend on. - Check the feature comparison. Microsoft publishes a comparison between Connect Sync and Cloud Sync. Anything you rely on that Cloud Sync lacks probably puts you in a later wave. - Read the migration guide and try Cloud Sync in a test environment or on a pilot OU. - Look at Source of Authority. Moving the source of authority for users or groups from AD to the cloud is a separate option, and you don't have to migrate sync first. For groups that no longer need to live in AD, it's worth considering. [Diagram: A sensible order of work for most tenants.] ## Running both side by side Connect Sync and Cloud Sync can run in the same tenant as long as they sync different objects. That's how most pilots work: scope Cloud Sync to a test OU, and exclude the same OU from Connect Sync. Never let both engines manage the same user, or they'll fight over its attributes. ## Questions to answer in your inventory - Which OUs and groups are in scope, and is any attribute filtering used? - Are there custom sync rules, and what do they do? - Is password writeback, group writeback or device writeback in use? - Are computer objects synced for hybrid join? - Which authentication method: password hash sync, pass-through or federation? - Is Exchange hybrid in use, with its attribute writeback? ## Hard match is now blocked for privileged users When sync adds an AD object, Entra looks for an existing cloud object with a matching OnPremisesImmutableId. If it finds one, sync takes over that cloud object and overwrites it with the AD object's properties. This is a hard match. That's useful when connecting existing cloud accounts to AD. It's also an attack path: someone with control over AD attributes could hard-match to a privileged cloud-only admin and take it over. Since 1 June 2026, Entra blocks sync from hard-matching a new AD user to a cloud user that holds an Entra role. Soft matching, hard matching for users without roles, and existing synced objects are unaffected. If you hit it: sync reports an existing admin role conflict. That's by design. Remove the role from the cloud account, complete the match, then reassign the role, ideally as PIM eligible. [Diagram: What happens when sync tries to match an on-premises user to a cloud account.] **Do I have to move to Cloud Sync straight away?** No. Microsoft is moving tenants in phases and will tell you when yours is due. Use the time to inventory and pilot so there are no surprises. **What about pass-through authentication and seamless SSO?** Hybrid authentication features stay available through the Connect Sync configuration wizard. Cloud Sync takes over identity synchronisation. **Is device sync for hybrid join covered?** Check the current feature comparison. If you rely on syncing computer objects, look at Entra join for new devices, or the Entra Kerberos hybrid join preview (https://azureblog.co.uk/posts/hybrid-join-with-entra-kerberos-preview/). Sources - Microsoft Learn: What's new in Microsoft Entra (https://learn.microsoft.com/en-us/entra/fundamentals/whats-new) - Microsoft Learn: Migrate from Connect Sync to Cloud Sync (https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/migrate-azure-ad-connect-to-cloud-sync) - Microsoft Learn: Connect Sync and Cloud Sync comparison (https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/connect-to-cloud-sync-decision-guide#comparison-between-microsoft-entra-connect-and-cloud-sync) - Microsoft Learn: Existing admin role conflict (https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/tshoot-connect-sync-errors#existing-admin-role-conflict) --- # Intune's advanced features are coming to Microsoft 365 E3 and E5 URL: https://azureblog.co.uk/posts/intune-suite-in-m365-e3-e5/ Published: 2026-07-02 Tags: Intune, Microsoft 365, What's new > Remote Help, Endpoint Privilege Management, Cloud PKI and more are moving into the main Microsoft 365 licences. If you've been holding off because of the add-on cost, it's time to look again. Many of Intune's best features have been paid add-ons, sold separately or in the Intune Suite. That made them easy to admire and hard to justify. Microsoft is now folding them into Microsoft 365 E3 and E5. ## What you get | Licence | Adds | M365 E3 | Remote Help, Advanced Analytics, and Intune Plan 2 (Microsoft Tunnel for MAM, specialty device management, and firmware-over-the-air updates for supported devices) | M365 E5 | Everything in E3, plus Endpoint Privilege Management, Enterprise Application Management and Microsoft Cloud PKI [Diagram: How the capabilities stack up.] ## How it rolls out - It's gradual, and eligible tenants are provisioned automatically. There's nothing to buy or assign. - Microsoft posts a notice in the Microsoft 365 admin center 30 days before the change reaches your tenant. - It covers commercial E3 and E5 only. Education and frontline plans aren't changing for now, and government plans will follow, subject to compliance requirements. ## What to do with it - Endpoint Privilege Management (E5). Lets standard users run specific approved tasks with elevation, without being local admins. If you still hand out local admin rights for one or two apps, this is the quickest security win on the list. - Enterprise Application Management (E5). A catalogue of pre-packaged Win32 apps that Intune can deploy and keep updated. Less packaging, fewer outdated apps. - Cloud PKI (E5). Issue certificates for Wi-Fi, VPN and other authentication from the cloud, without running your own certificate servers and connectors. - Remote Help (E3). Secure, Entra-authenticated remote support built into Intune, with role-based access and logging. - Retire overlapping tools. If you're paying for separate remote support, privilege management or PKI products, check renewal dates now. Watch for the notice: when the 30-day notice arrives, that's your cue to plan pilots. Having the licence doesn't configure anything, so nothing changes for users until you do. ## Where to start [Diagram: Picking the first feature to adopt.] ## An Endpoint Privilege Management pilot - List the reasons users currently need local admin, from your service desk tickets. - Create elevation rules for the most common ones, such as a specific installer or tool. - Pilot with a team that has admin rights today, then remove their local admin membership. - Review the elevation reports weekly and add rules where requests repeat. Sources - Microsoft Learn: What's new in Microsoft Intune (https://learn.microsoft.com/en-us/intune/whats-new/) - Microsoft Learn: Microsoft Intune advanced capabilities (https://learn.microsoft.com/en-us/intune/fundamentals/advanced-capabilities) --- # Entra Backup and Recovery is here: an undo button for your tenant URL: https://azureblog.co.uk/posts/entra-backup-and-recovery/ Published: 2026-06-24 Tags: Entra ID, What's new > Entra ID now keeps daily backups of your critical directory objects and lets you compare and roll back changes. It's on by default, but you need to know how it works before you need it. For years, recovering from a bad change in Entra ID meant hoping the object was soft-deleted, or rebuilding it from documentation, exports or memory. A deleted Conditional Access policy or a mangled set of group memberships could take hours to reconstruct. Entra Backup and Recovery, now generally available, changes that. ## How it works - Always on. Entra takes one backup a day automatically. There's nothing to enable. - Seven days of history. Backups from the last seven days are kept, stored in the same geography as your tenant. - Tamper-proof. Nobody, including Global Administrators, can turn backups off, delete them or edit them. That matters if an attacker gets privileged access. - Licensing. It needs a workforce tenant with Entra ID P1 or P2. External ID and B2C tenants aren't supported. [Diagram: Seven daily backups, always on. Pick the one from before the change.] ## What's covered Users, groups, applications, service principals, Conditional Access policies, named locations, the authentication methods policy and selected authorization policy settings. Agent identities are covered too, because they're built from user and service principal objects. It restores supported properties and links on objects that still exist. It doesn't bring back hard-deleted objects. For deleted users, groups and apps, the existing 30-day soft-delete recycle bin is still your first stop. ## Recovering from a bad change - In the Entra admin center, open Backup and recovery. - Under Backups, pick a snapshot from before the change. - Create a Difference report. It shows exactly which attributes and links differ from the current state. - Review it carefully, then use Recover objects to restore everything, specific object types or specific object IDs. - Track progress under Recovery history. Always review the difference report first. A recovery rolls back every change to the selected objects since that backup, including legitimate ones made by other admins. [Diagram: Which recovery tool do you need?] ## Things to plan for - Roles. There are two new built-in roles: Backup Reader to view backups and differences, and Backup Administrator to run recoveries. Put the administrator role behind PIM. - Hybrid objects. For objects synced from Active Directory, you can produce difference reports but can't recover them in Entra. Fix those at the source in AD. - Seven days is short. If a bad change goes unnoticed for a week, it's beyond reach. Keep your audit log alerts for high-impact changes, like Conditional Access edits. - Practise. Make a harmless change in a test tenant and recover it, so the process isn't new on the day it matters. ## Practise before you need it - Run a difference report against yesterday's backup, just to see what normal change looks like - In a test tenant, change a Conditional Access policy and restore it - Decide who may restore, and require PIM activation for that role - Write the steps into your incident runbook - Keep your own exports of critical configuration for anything older than seven days ## Why tamper-proof matters An attacker with Global Administrator can delete objects, weaken policies and cover their tracks. Backups they can't switch off or edit give you a known-good state to compare against, which is useful for investigation as well as recovery. **Does a restore overwrite everything?** No. You choose what to restore after reviewing the difference report, so you can roll back one policy or a set of group memberships without touching anything else. **Can I extend retention beyond seven days?** Not today. For longer history, keep your own snapshots, for example with tenant configuration management (https://azureblog.co.uk/posts/entra-tenant-configuration-management/) stored in Git. Sources - Microsoft Learn: Entra Backup and Recovery overview (https://learn.microsoft.com/en-us/entra/backup/overview) - Microsoft Learn: Recover objects (https://learn.microsoft.com/en-us/entra/backup/recover-objects) - Microsoft Learn: What's new in Microsoft Entra (https://learn.microsoft.com/en-us/entra/fundamentals/whats-new) --- # Account Discovery: find the accounts your SaaS apps forgot to tell you about URL: https://azureblog.co.uk/posts/entra-account-discovery-ga/ Published: 2026-06-17 Tags: Entra ID, Governance, What's new > Account Discovery reports the accounts that exist inside connected applications, including orphaned ones that nobody in Entra was ever assigned. It's now generally available. Provisioning and SSO tell you who should have access to an app. They don't always tell you who does. Apps collect accounts over the years: created locally by an app admin, left behind after a migration, or belonging to people who left long ago. [Diagram: What Entra knows versus what the app holds.] Account Discovery reports the accounts that exist in your connected applications, and flags orphaned accounts: accounts in the app that don't correspond to an assignment in Entra. It's generally available and requires Entra ID Governance or Entra Suite licensing. ## Using it well - Start with high-risk apps: finance, HR, anything holding client data, and any app with its own admin accounts. - Review the orphaned accounts with the app owner. Some will be service or break-glass accounts that are meant to be there; document those. - Disable the rest in the app, and fix the process that created them. - Bring legitimate users under Entra assignment so future joiners and leavers are handled automatically. Good for audits: "show me every account in this system and who owns it" is a common audit request. This answers it from one place. [Diagram: Working through an orphaned account.] ## Making it stick - Agree an owner for each in-scope app before you start - Bring the app's discovered accounts into your regular access reviews - Turn on provisioning where the app supports it, so new accounts start in Entra - Remove local account creation rights from app admins where you can - Re-run discovery after each clean-up to show the trend **Which apps does it work with?** Apps connected to Entra for provisioning and governance. Check the documentation for the current list of supported connectors. **Will it change anything in the app?** Discovery reports. Changes are yours to make, either in the app or through provisioning. Sources - Microsoft Learn: What's new in Microsoft Entra (https://learn.microsoft.com/en-us/entra/fundamentals/whats-new) --- # Soft delete for Entra device objects: a safety net for device clean-ups URL: https://azureblog.co.uk/posts/entra-device-soft-delete-preview/ Published: 2026-06-10 Tags: Entra ID, Windows, What's new > Deleted device objects can now go into a recoverable state instead of disappearing instantly. A small preview feature that takes the fear out of stale device clean-ups. Every tenant collects stale device objects: machines rebuilt, replaced or lost years ago. Cleaning them up is good hygiene, but deleting the wrong device is painful. Its identity, the BitLocker recovery keys stored against it and other security data go with it. [Diagram: A device's journey from active to gone.] A new preview adds soft delete for device objects. Deleted devices move into a recoverable state and can be restored within a retention period, with their identity and associated security artifacts intact. It covers Entra joined, Entra registered and hybrid joined devices. ## A safer stale-device process - Find devices with no sign-in activity for a long period, such as 90 days or more, using the approximateLastSignInDateTime property. - Disable them first and wait. If nobody complains, move on. - Check Intune and your other tools so you're not deleting a device that's still managed. - Delete in batches. With soft delete, a mistake can be restored rather than rebuilt. ``` Connect-MgGraph -Scopes "Device.Read.All" $cutoff = (Get-Date).AddDays(-90) Get-MgDevice -All -Property DisplayName,OperatingSystem,ApproximateLastSignInDateTime,AccountEnabled | Where-Object { $_.ApproximateLastSignInDateTime -lt $cutoff } | Sort-Object ApproximateLastSignInDateTime | Select-Object DisplayName, OperatingSystem, ApproximateLastSignInDateTime, AccountEnabled ``` Preview caveat: while it's in preview, check the documentation for the current retention period before relying on it. ## Before you delete anything | Check | Why | Is it still in Intune? | A device that checks in with Intune but shows an old sign-in date may just be a device nobody signs in to interactively, such as a kiosk. | Are BitLocker keys stored against it? | If the disk might still be needed, export the recovery key first. | Is it a hybrid joined device? | Deleting it in Entra while it still exists in AD and syncs brings it back. Clean up in AD first. | Is it an Autopilot device? | Autopilot registrations are separate. Remove them only when the hardware is really leaving. ## Disable in bulk ``` Connect-MgGraph -Scopes "Device.ReadWrite.All" $cutoff = (Get-Date).AddDays(-90) $stale = Get-MgDevice -All -Property Id,DisplayName,ApproximateLastSignInDateTime,AccountEnabled | Where-Object { $_.AccountEnabled -and $_.ApproximateLastSignInDateTime -lt $cutoff } $stale | Export-Csv stale-devices.csv -NoTypeInformation # keep a record $stale | ForEach-Object { Update-MgDevice -DeviceId $_.Id -AccountEnabled:$false } ``` **Does disabling a device wipe it?** No. It stops the device authenticating to Entra, which blocks device-based access. Wiping is an Intune action. **What's the benefit over just disabling?** Disabled devices still clutter the directory and count against limits. Soft delete lets you finish the clean-up while keeping a way back. Sources - Microsoft Learn: What's new in Microsoft Entra (https://learn.microsoft.com/en-us/entra/fundamentals/whats-new) --- # Cross-tenant group sync is GA: one group, many tenants URL: https://azureblog.co.uk/posts/cross-tenant-group-sync-ga/ Published: 2026-06-03 Tags: Entra ID, Governance, What's new > Multi-tenant organisations can now sync security groups from a source tenant into target tenants, alongside the users already synced with cross-tenant sync. Cross-tenant synchronisation has been able to provision users from one Entra tenant into another for a while. That solved half the problem for multi-tenant organisations, such as groups with separate tenants per subsidiary or after an acquisition. The other half was groups: access in the target tenant still had to be granted by hand. [Diagram: One source group, consumed in several tenants.] Cross-tenant group synchronisation, now generally available, syncs security groups from a source tenant to target tenants. Users and their group memberships arrive together. ## Why it matters - Single source of truth. Manage membership once in the home tenant, and access follows into every tenant that consumes the group. - Cleaner offboarding. Remove someone from the source group and they lose access everywhere it's synced. - Fewer duplicate groups with slightly different names and memberships in each tenant. ## How it works [Diagram: Users and their groups arriving in a target tenant.] It builds on the cross-tenant synchronisation setup you may already have. The source tenant runs a sync configuration that scopes users and groups. The target tenant has to allow it in its cross-tenant access settings, with inbound user sync and automatic redemption enabled for the source tenant. ## Before you start - Licensing. Group sync needs Entra ID Governance licences. - Scope carefully. Only sync the groups the target tenant actually uses for access. - Agree ownership. Decide who in the target tenant may assign synced groups to apps and roles, and who can change them in the source. - Cross-tenant sync for users already working between the tenants - Inbound sync allowed in the target's cross-tenant access settings - Entra ID Governance licences in place - A short list of groups the target actually needs - Naming agreed, so synced groups are recognisable in the target - Owners in both tenants who know who changes what ## What it doesn't do - It syncs security groups for access. It isn't a way to replicate every Microsoft 365 group and its content between tenants. - Groups are managed at the source. Changes made to the synced copy in the target are overwritten. - Nested and dynamic group behaviour can differ from what you expect. Check the documentation for the current support before you design around it. **Do target admins lose control?** They keep control over what synced groups can access. They just don't manage membership, which is the point. **Can I use this for a merger?** Yes, it's a strong fit while tenants coexist. It doesn't replace a tenant-to-tenant migration if the end goal is one tenant. Sources - Microsoft Learn: What's new in Microsoft Entra (https://learn.microsoft.com/en-us/entra/fundamentals/whats-new) --- # System-preferred authentication now picks the first factor too URL: https://azureblog.co.uk/posts/system-preferred-first-factor-passwordless/ Published: 2026-05-27 Tags: Entra ID, Passkeys, What's new > Users with a passkey may now sign in without being asked for a password at all, and registration campaigns can prompt for passkeys. Two changes that quietly push tenants towards passwordless. ## System-preferred, first factor included System-preferred authentication has been choosing the strongest second factor a user has registered for a while. It now applies to the first factor as well, in the Microsoft-managed state. Entra looks at the user's registered credentials and picks the highest-ranked method for each step. [Diagram: With system-preferred authentication, Entra offers the strongest method the user has.] In practice, a user with a passkey can be offered the passkey straight away and sign in without typing a password. Nothing changes for users who only have a password and a weaker second factor. ## Passkeys in registration campaigns The registration campaign (the "nudge" that prompts users at sign-in to set up a better method) can now target passkeys. That's the easiest way to drive adoption at scale: users are prompted at sign-in, can register in a minute, and IT doesn't have to chase anyone by email. The initial rollout is optimised for users in a passkey profile without restrictions. ## What to check - Is your tenant Microsoft-managed? The first-factor change only applies in the Microsoft-managed state. If you've explicitly disabled system-preferred authentication, you won't see it. - Tell the service desk. Users suddenly not being asked for a password will generate a few "is this safe?" calls. - Plan the campaign. Decide who's in scope, whether users can snooze and for how long, and communicate before switching it on. ## What users actually see - Users with a passkey are offered it straight away. Many will never type a password again. - Users with Authenticator but no passkey still enter a password, then get the strongest second factor they have. - Users with only a password and SMS see no change, except the registration campaign nudging them to add something stronger. A user can still choose another method from the "Other ways to sign in" link. System-preferred changes the default, not the options. ## Measuring progress The Authentication methods activity report in the Entra admin center shows how many users are registered for each method and which methods they actually use to sign in. Watch the passwordless-capable percentage climb as the campaign runs. **Does this remove passwords from accounts?** No. The password still exists; the user just isn't asked for it when a stronger first factor is available. **Can I turn system-preferred authentication off?** Yes, but the first-factor change only applies in the Microsoft-managed state, and Microsoft recommends leaving it on. Sources - Microsoft Learn: What's new in Microsoft Entra (https://learn.microsoft.com/en-us/entra/fundamentals/whats-new) - Microsoft Learn: Enable passkeys (FIDO2) in Entra ID (https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-passkeys-fido2) --- # Rolling out "require compliant device" without a flood of tickets URL: https://azureblog.co.uk/posts/rolling-out-require-compliant-device/ Published: 2026-05-20 Tags: Intune, Conditional Access, Entra ID > Requiring a compliant device is one of the strongest Conditional Access controls you can apply. It's also one of the easiest to get wrong. A step-by-step rollout. A Conditional Access policy that requires a compliant device means only devices managed by Intune and meeting your compliance rules can reach corporate data. Stolen passwords and tokens become far less useful. The challenge is rolling it out without blocking people who are doing nothing wrong. [Diagram: How compliance reaches a Conditional Access decision.] ## 1. Get compliance right first - Make sure every platform you allow has a compliance policy assigned. - Review the tenant setting Mark devices with no compliance policy assigned as. Set it to Not compliant, so a missing policy isn't a free pass. - Use a sensible grace period for non-urgent settings, so a device isn't blocked the moment something minor changes. - Check the compliance report and fix the common failures, often OS version, BitLocker or Defender. ## 2. Run the policy in report-only Create the Conditional Access policy targeting all users and all cloud apps, with the grant control Require device to be marked as compliant. Leave it in report-only for a week or two and review who would be blocked. ## 3. Plan the exceptions - Break-glass accounts: always excluded. - Guests: their devices are managed by their own organisation. Either exclude them or trust their compliance claims in cross-tenant access settings. - Personal devices: decide whether they're blocked or allowed limited browser access through a separate policy. - Device enrolment: new devices need to reach Intune before they're compliant. Check that enrolment and the Company Portal aren't blocked. [Diagram: Deciding what each group gets.] ## 4. Enforce in waves Turn it on for IT first, then pilot departments, then everyone. Brief the service desk with the common fixes: run a compliance check in Company Portal, install pending updates, enable BitLocker. Platform tip: on iOS and Android, users access apps through the browser or apps that support device state. Microsoft Edge is the safest choice on mobile for web apps behind this policy. ## What users will see When a device fails, the user gets a message that the device must be managed or compliant, with a link to Company Portal or settings to fix it. On Windows, the most common fixes are installing updates and restarting. The compliance troubleshooting wizard (https://azureblog.co.uk/tools/troubleshoot/?t=compliance) walks the service desk through the rest. ## Watching the rollout - Filter sign-in logs for Conditional Access failures with error 53000 (device not compliant) each morning of the rollout. - Watch the Intune compliance report for devices stuck in "Not evaluated". - Keep the previous wave stable for a few days before starting the next. --- # Packaging Win32 apps for Intune: detection rules and return codes URL: https://azureblog.co.uk/posts/win32-app-packaging-detection-rules/ Published: 2026-05-13 Tags: Intune, Windows > Most Win32 app failures in Intune come down to two things: a detection rule that doesn't match reality, and return codes Intune doesn't understand. ## Wrapping the app Intune deploys Win32 apps as .intunewin files created with the Microsoft Win32 Content Prep Tool: [Diagram: What Intune does when it installs a Win32 app.] ``` IntuneWinAppUtil.exe -c C:\Packages\7zip -s 7z-x64.msi -o C:\Packages\Output ``` Everything in the source folder is included, so keep it tidy: the installer, any transforms and scripts, nothing else. ## Install and uninstall commands Both must run silently, with no user interaction: ``` msiexec /i "7z-x64.msi" /qn /norestart msiexec /x {23170F69-40C1-2702-0000-000001000000} /qn /norestart ``` ## Detection rules decide everything After installing, Intune runs your detection rule. If it doesn't find the app, the install is marked as failed, even if it worked perfectly. Choose the most reliable signal: - MSI product code: best for MSIs. It can check the version too. - File or folder: check a file exists, optionally with a minimum version. Watch for 32-bit apps on 64-bit Windows, and tick the 32-bit option if needed. - Registry: an uninstall key or a value the installer writes. - Script: for complex cases. The app counts as detected if the script exits 0 and writes something to standard output. [Diagram: Choosing a detection rule.] ## Return codes Intune needs to know what each installer exit code means. The defaults cover the common ones: | Code | Meaning | 0 | Success | 1707 | Success | 3010 | Soft reboot: success, restart needed | 1641 | Hard reboot: the installer started a restart | 1618 | Retry: another installation is in progress Vendor installers often have their own codes. Check the vendor's documentation and add them. ## Testing Test the install and uninstall commands as SYSTEM before uploading, for example using PsExec with -s. Then assign to a test device and check the logs in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. ## Supersedence and dependencies - Supersedence replaces an older app with a newer one. You can choose to uninstall the old version first or update in place. - Dependencies install another Win32 app first, such as a runtime the main app needs. ## Common failures | Symptom | Usual cause | Installs, but shows as failed | Detection rule doesn't match what the installer actually wrote | Stuck on "Installing" | The installer is waiting for input. The command isn't really silent | Error 0x87D1041C | The app was detected as not installed after the install ran | Works on some devices only | 32-bit versus 64-bit paths, or a missing dependency --- # Entra Agent ID: giving AI agents real identities URL: https://azureblog.co.uk/posts/entra-agent-id-identities-for-ai-agents/ Published: 2026-05-06 Tags: Entra ID, Security, Governance, What's new > AI agents now get first-class identities in Entra, with Conditional Access and lifecycle controls following. Here's why identity teams should get involved early. AI agents act on behalf of people and organisations. They read data, call APIs and increasingly take actions. Until recently they did it with whatever credentials were to hand: an app registration, a service account, or a user's own token. That's hard to govern. [Diagram: Everything an agent identity should be connected to.] Microsoft Entra Agent ID, now generally available, is an identity and authorisation framework for AI agents, built on OAuth 2.0 and supporting the Model Context Protocol (MCP) and agent-to-agent (A2A) scenarios. ## What's arriving around it - Sponsorship lifecycle (GA). Agent identities have a human sponsor. When that sponsor leaves, Lifecycle Workflows can transfer sponsorship to their manager, so no agent is left without an owner. - Conditional Access for agents (preview). Policies can target agent user accounts using custom security attributes, agent risk, device compliance and network conditions. - Registry changes. Microsoft has consolidated the Entra agent registry into Microsoft Agent 365. Check the current documentation if you registered agents through the earlier API. ## What identity teams should do now - Inventory existing agents and what they authenticate with. Shared service accounts and long-lived secrets are the first things to replace. - Insist on a sponsor for every agent, just as every app registration should have owners. - Apply least privilege. An agent with broad Graph permissions is a large, automated attack surface. - Log and review. Treat agent sign-ins like any other workload identity and include them in your monitoring. ## Shared credentials versus agent identities [Diagram: Why the old approach doesn't scale.] ## Questions to ask about any agent - Is it acting as itself, or on behalf of a signed-in user? - Which data and APIs can it reach, and does it need all of them? - Who is the sponsor, and who takes over when they leave? - Can it be switched off quickly if it misbehaves? - Are its sign-ins and actions in your SIEM? **Is an agent identity just a service principal?** It's built on the same foundations, but with agent-specific features such as sponsorship and agent-aware policy. That's why Entra Backup and Recovery covers them alongside users and service principals. **Do I need this if we don't build agents?** Probably soon. Products you buy increasingly ship agents that act in your tenant. Knowing how they authenticate and what they can touch is part of approving them. Sources - Microsoft Learn: What's new in Microsoft Entra (https://learn.microsoft.com/en-us/entra/fundamentals/whats-new) --- # Configurable token lifetimes are GA: when to shorten them (and when not to) URL: https://azureblog.co.uk/posts/configurable-token-lifetimes-ga/ Published: 2026-04-29 Tags: Entra ID, Security, What's new > You can now set the lifetime of access, ID and SAML tokens per application. Useful for sensitive apps, but there are better tools for most session problems. Token lifetime policies let you change how long access tokens, ID tokens and SAML tokens from the Microsoft identity platform stay valid. You create a policy and assign it to specific applications or service principals. [Diagram: Which tool controls which part of a session.] ## When it helps - Sensitive applications. A shorter access token lifetime means a stolen token is useful for less time. - SAML apps with long sessions. Controlling the SAML token lifetime can tighten how long an assertion is accepted. - Long-running automation. In some cases a longer access token lifetime reduces token refresh churn. ## When it doesn't Token lifetime policies don't control refresh tokens or session tokens. If the problem is "how often should users sign in again?", the answer is Conditional Access session controls: - Sign-in frequency sets how often users must reauthenticate. - Persistent browser session controls whether the browser stays signed in after it closes. - Continuous access evaluation (CAE) lets supporting services revoke access quickly when something changes, such as a disabled account or a new location, without needing short tokens everywhere. ## Practical guidance - Change lifetimes only for specific apps with a clear reason. Don't apply a short lifetime tenant-wide. - Test with the app owner. Some apps behave badly when tokens expire mid-session. - Document the policy and why it exists, so the next engineer doesn't remove it or copy it blindly. ## Choosing a lifetime [Diagram: Do you need a token lifetime policy at all?] ## Testing a change - Create the policy and assign it to a test copy of the app, or the real app with a pilot group. - Sign in, then decode the access token with the JWT decoder (https://azureblog.co.uk/tools/jwt/) and compare iat and exp to confirm the new lifetime. - Use the app past the lifetime to make sure it renews tokens quietly instead of failing. - Roll out to everyone and record why the policy exists. Sources - Microsoft Learn: Configurable token lifetimes (https://learn.microsoft.com/en-us/entra/identity-platform/configurable-token-lifetimes) - Microsoft Learn: What's new in Microsoft Entra (https://learn.microsoft.com/en-us/entra/fundamentals/whats-new) --- # Require phishing-resistant MFA on every PIM activation URL: https://azureblog.co.uk/posts/pim-activation-conditional-access-context/ Published: 2026-04-22 Tags: Entra ID, Governance, Conditional Access, What's new > PIM can now require a Conditional Access authentication context every time someone activates a role, and it's generally available. Here's how to set it up properly. Privileged Identity Management has always been able to require MFA on activation. The problem is that a user who already signed in with MFA often isn't challenged again, and any MFA method counts, including weaker ones. Requiring a Conditional Access authentication context on activation fixes both: you decide exactly what the user must prove, and it's checked every time they activate. [Diagram: Activation with an authentication context.] ## How it fits together - Authentication context is a label, such as "Privileged activation", that apps and services can request. - A Conditional Access policy targets that label and sets the requirements, for example phishing-resistant MFA from a compliant device. - PIM requests the label when someone activates a role, so the policy is enforced at that moment. ## Setting it up - Create the context. In the Entra admin center, go to Conditional Access → Authentication contexts and create one, for example Privileged role activation. Make sure it's published to apps. - Create the policy. Make a new Conditional Access policy targeting your admins. Under Target resources, choose Authentication context and select it. Under Grant, require the Phishing-resistant MFA authentication strength. Optionally add a compliant device requirement and a sign-in frequency of every time. - Test in report-only mode, then switch it on. - Configure PIM. Go to Identity governance → Privileged Identity Management → Microsoft Entra roles → Settings, pick a role and choose Edit. Under activation, select On activation, require Microsoft Entra Conditional Access authentication context and choose your context. - Repeat for each high-value role, starting with Global Administrator, Privileged Role Administrator, Security Administrator and Conditional Access Administrator. ## Things to watch - Make sure admins have a passkey first. If you require phishing-resistant MFA, admins without a passkey or security key can't activate. Use a registration campaign or passkey profile ahead of time. - Exclude your break-glass accounts from the policy, and monitor their sign-ins separately. - Apply it to PIM for Groups too if you use groups to grant privileged access. The same setting exists in group role settings. Why bother: stolen sessions and phishing kits that relay MFA prompts are common. An attacker holding a stolen token still can't elevate if each activation demands a fresh, phishing-resistant sign-in. [Diagram: Plain MFA on activation versus an authentication context.] - Exclude break-glass accounts from the policy - Make sure every admin has a phishing-resistant method registered first - Test in report-only mode, then use What If - Apply the context to every privileged role, not just Global Administrator - Check scripted activations still work, since the token must satisfy the context **Do I still need the MFA on activation setting?** No. The authentication context replaces it and does more. Use one or the other per role. **Does it work for Azure resource roles and groups?** Yes. PIM for Azure roles and PIM for Groups can require an authentication context too. Sources - Microsoft Learn: What's new in Microsoft Entra (https://learn.microsoft.com/en-us/entra/fundamentals/whats-new) - Microsoft Learn: Require Conditional Access authentication context on activation (https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/groups-role-settings#on-activation-require-microsoft-entra-conditional-access-authentication-context) --- # Intune Remediations: find and fix problems before users notice URL: https://azureblog.co.uk/posts/intune-remediations-scripts/ Published: 2026-04-15 Tags: Intune, Windows, PowerShell > Remediations pair a detection script with a fix script and run them on a schedule. It's one of the most useful and underused features in Intune. Remediations (once called Proactive Remediations) run a pair of PowerShell scripts on Windows devices on a schedule. The detection script checks for a problem. If it finds one, the remediation script fixes it. Intune reports on both, so you can see how many devices had the problem and how many were fixed. ## How the scripts talk to Intune - Exit 0 from detection means "all good". Nothing else runs. - Exit 1 from detection means "problem found". The remediation script runs. - Whatever the script writes to output appears in the Intune report, so write something useful. [Diagram: What happens on each run.] ## Example: clear a full temp folder Detection: ``` $sizeGB = (Get-ChildItem "$env:SystemRoot\Temp" -Recurse -Force -ErrorAction SilentlyContinue | Measure-Object Length -Sum).Sum / 1GB if ($sizeGB -gt 5) { Write-Output "Temp is $([math]::Round($sizeGB,1)) GB"; exit 1 } Write-Output "Temp OK"; exit 0 ``` Remediation: ``` Get-ChildItem "$env:SystemRoot\Temp" -Recurse -Force -ErrorAction SilentlyContinue | Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-7) } | Remove-Item -Recurse -Force -ErrorAction SilentlyContinue Write-Output "Cleaned temp folder"; exit 0 ``` ## Good uses - Restarting a service that keeps stopping - Fixing a registry value that users or apps keep changing - Detection-only reports, such as finding devices with a specific app version or a certificate about to expire ## Things to know - Licensing: Remediations needs Windows Enterprise E3/E5 or equivalent (included in Microsoft 365 E3/E5). - Context: scripts run as SYSTEM by default. Choose "run as logged-on user" for user-level fixes. - Use Run remediation on a single device for on-demand fixes from the device page. ## Writing scripts that behave - Make detection read-only: it should only check, never change anything - Make remediation safe to run twice (idempotent) - Write one clear line of output: it appears in the Intune report columns - Keep scripts short and fast: they run on every device in scope - Sign scripts if your devices enforce signed PowerShell, or allow unsigned in the remediation settings ## Reading the results In Intune, open Devices → Scripts and remediations → Remediations and select the package. The overview shows how many devices had the issue, how many were fixed and how many failed. The device status view adds the detection and remediation output for each device, so useful output lines pay off here. ## Troubleshooting - Logs are on the device under C:\ProgramData\Microsoft\IntuneManagementExtension\Logs, mainly AgentExecutor.log and IntuneManagementExtension.log. - A script that works in your console but fails in Intune is usually running as SYSTEM, where user paths and mapped drives don't exist. - 64-bit versus 32-bit PowerShell changes which registry view you see. Choose 64-bit in the package settings if you read HKLM\SOFTWARE. --- # Tenant configuration management: snapshot your Entra config and catch drift URL: https://azureblog.co.uk/posts/entra-tenant-configuration-management/ Published: 2026-04-08 Tags: Entra ID, Governance, What's new > New APIs let you snapshot tenant configuration as JSON and monitor it for drift. Configuration as code for Entra just got much more practical. Most Entra tenants are configured by hand, one portal click at a time. That works until someone changes a setting nobody wrote down, and the question becomes "what was it before?" [Diagram: Baseline, monitor, alert.] Tenant configuration management APIs, now generally available, let you take a snapshot of tenant configuration as JSON and set up monitors that detect drift from a known-good baseline. An admin center experience for managing monitors is in preview. ## Ways to use it - Baseline after a change. When a CAB-approved change goes in, snapshot the result. That becomes the reference. - Drift alerts. Monitor the settings that matter most, such as authentication methods, Conditional Access and external collaboration, and alert on unexpected changes. - Multi-tenant consistency. Compare test and production tenants, or several production tenants, against the same baseline. - Store snapshots in Git. A JSON snapshot in source control gives you a readable history of your tenant over time. ## How it fits with backup Entra Backup and Recovery restores directory objects from the last few days. Configuration snapshots answer a different question: is my tenant still configured the way I intended? Use both. [Diagram: Two tools, two questions.] ## What to monitor first - Authentication methods policy - Conditional Access policies and named locations - External collaboration and cross-tenant access settings - User consent and app registration settings - Privileged role settings **Will a monitor stop someone making a change?** No. It detects and reports. Prevention is still Conditional Access, PIM and change control. **How do I handle approved changes?** Update the baseline as the last step of the change. If a monitor fires and there's no matching change record, that's worth a look. Sources - Microsoft Learn: What's new in Microsoft Entra (https://learn.microsoft.com/en-us/entra/fundamentals/whats-new) --- # Hybrid join without Entra Connect: hybrid join using Entra Kerberos URL: https://azureblog.co.uk/posts/hybrid-join-with-entra-kerberos-preview/ Published: 2026-04-01 Tags: Entra ID, Hybrid identity, Windows, What's new > A new preview lets Windows devices become Entra hybrid joined during provisioning, without device sync through Entra Connect or AD FS. Hybrid join has always depended on plumbing: Entra Connect syncing computer objects and a service connection point, or AD FS in federated tenants. Devices often sat in a pending state until the next sync cycle, which confused users and slowed down rollouts. [Diagram: Two routes to a hybrid joined device.] A new preview lets devices become hybrid joined at provisioning time using Entra Kerberos, without Entra Connect device sync or AD FS. ## Why it's interesting - No waiting for sync. The device is hybrid joined when it's provisioned, so device-based Conditional Access works straight away. - Less infrastructure. It removes one more dependency on Connect Sync, in line with Microsoft's move to Cloud Sync. - Fewer pending devices. Hybrid join troubleshooting often comes down to sync timing and SCP configuration. This sidesteps most of it. ## Why traditional hybrid join is slow [Diagram: The classic hybrid join path, and where devices get stuck as pending.] Every step in that chain is a place for something to go wrong: the computer object outside the sync scope, a missing or wrong SCP, a sync cycle that hasn't run yet. Most hybrid join tickets come down to one of them. ## Should you use it? For new Windows deployments, the first question is still whether you need hybrid join at all. Entra join with Intune, and cloud Kerberos trust for access to on-premises resources, covers most needs. Where hybrid join is still required, such as apps or policies that depend on domain membership, this preview is worth testing in a lab now. [Diagram: Do you need hybrid join at all?] **Will this replace my existing hybrid joined devices?** No. It's about how new devices get joined. Existing devices carry on as they are. **Can I use it in production?** It's a preview. Test it in a lab and watch for general availability before relying on it. ## What to test in a lab - A new device built by your normal provisioning process ends up hybrid joined, not pending - Device-based Conditional Access works at the first user sign-in - Group Policy, domain-only apps and file shares still behave as expected - The device appears correctly in Intune if it's co-managed or enrolled - Your existing hybrid joined devices are unaffected Sources - Microsoft Learn: What's new in Microsoft Entra (https://learn.microsoft.com/en-us/entra/fundamentals/whats-new) --- # Clean up guest accounts with access reviews URL: https://azureblog.co.uk/posts/guest-access-reviews/ Published: 2026-03-25 Tags: Entra ID, Governance > Guest accounts pile up quietly. Access reviews ask the right people whether each guest still needs access, and can remove them automatically if nobody says yes. Every Teams invite and shared document can leave a guest account behind. A few years on, most tenants have hundreds or thousands of guests, many with access nobody remembers granting. [Diagram: A quarterly guest review with auto-apply.] ## What an access review does An access review asks reviewers to confirm whether each member of a group, team or app still needs access. You choose who reviews (group owners, managers, or the guests themselves), how often, and what happens to people nobody approves. ## A good guest review - Scope: all Microsoft 365 groups and Teams with guest members, guests only. - Reviewers: group owners, since they know who they work with. Use a fallback reviewer for groups without owners. - Recurrence: quarterly, with a two-week window. - If reviewers don't respond: remove access. Without this, a review that nobody completes changes nothing. - Auto-apply results, so removals happen without anyone clicking a button. ## Go one step further Removing a guest from a group doesn't delete their account. A separate review of all guest users in the tenant can block sign-in for guests who are denied, then delete them after a set period, such as 30 days. That stops dormant guest accounts building up. [Diagram: What happens to a guest who isn't approved, using the all-guests review.] ## Licensing Access reviews need Entra ID Governance licensing (or P2 for some scenarios). Reviewing guests uses a separate Entra ID Governance guest billing meter, which needs a linked Azure subscription. Tell owners first: a short message explaining why they're getting review emails dramatically improves completion rates. ## Making reviews easy for owners - Use recommendations. Reviews can show a recommendation based on recent sign-in activity, which helps owners decide quickly. - Keep the window realistic. Two weeks with reminders works better than a few days. - Explain the email. Owners often ignore review emails they don't recognise. A short Teams post first makes a big difference. ## Measuring the effect Track the number of guests and the percentage that are stale (no sign-in for 90 days) before and after the first few reviews. The tenant health check (https://azureblog.co.uk/tools/health/) reports both. --- # Synced passkeys and passkey profiles are now GA in Entra ID URL: https://azureblog.co.uk/posts/synced-passkeys-and-passkey-profiles/ Published: 2026-03-18 Tags: Entra ID, Passkeys, What's new > Entra ID now supports passkeys stored in password managers and phone platforms, and lets you set different passkey rules for different groups. Here's how to use both sensibly. Two passkey features reached general availability together, and they're designed to be used as a pair. [Diagram: The trade-off between the two passkey types.] ## Synced passkeys Until now, Entra passkeys were device-bound: tied to one security key or one phone's authenticator. Synced passkeys live in a passkey provider, such as the built-in platform provider on a phone or a third-party password manager, and are available across all of a user's devices. The trade-off is simple. Synced passkeys are far easier for users: lose a phone, and the passkey is still there on the next device. Device-bound passkeys give you stronger guarantees about exactly where the key lives. ## Passkey profiles Passkey profiles let you define several sets of passkey rules in the authentication methods policy and target each at different groups. Each profile controls: - which passkey types are allowed (device-bound, synced, or both) - whether attestation is enforced - which authenticators are allowed or blocked If you already had passkeys configured, those settings moved into a default profile automatically. Later updates raised the limit to 10 profiles per tenant and gave the passkey policy its own storage allowance. ## A sensible starting design | Profile | Who | Rules | Admins | Privileged role holders | Device-bound only, attestation enforced, approved security keys or Authenticator | Standard | Everyone else | Device-bound or synced, no attestation This gets most users onto phishing-resistant sign-in with very little friction, while keeping a tighter grip on the accounts attackers want most. Pair it with Conditional Access: once users have passkeys, require the Phishing-resistant MFA authentication strength for admin portals and sensitive apps. ## How Entra decides which rules apply Each passkey profile is targeted at groups. When a user registers or uses a passkey, Entra applies the profile assigned to them. Keep the targeting simple: one restrictive profile for privileged users, one relaxed profile for everyone else, and a clear rule for who goes where. Profiles that overlap in unclear ways become hard to support. [Diagram: How profiles narrow down what's allowed.] ## Rolling it out - Check what your existing passkey settings migrated into. Tenants that already had passkeys configured get a default profile with those settings. - Create the admin profile first and test it with two or three admins, including registration on a new device. - Widen the standard profile to allow synced passkeys, then run a registration campaign. - Once most users have a passkey, require the phishing-resistant MFA (https://azureblog.co.uk/posts/authentication-strengths-explained/) authentication strength for sensitive apps. ## Checklist - Decide which groups may use synced passkeys - Create an admin profile with device-bound keys and attestation - Test registration and sign-in on Windows, iOS and Android - Brief the service desk on lost-device recovery with a Temporary Access Pass - Add Conditional Access authentication strengths once adoption is high Sources - Microsoft Learn: Enable passkeys (FIDO2) in Entra ID (https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-passkeys-fido2) - Microsoft Learn: What's new in Microsoft Entra (https://learn.microsoft.com/en-us/entra/fundamentals/whats-new) --- # Six KQL queries for Entra sign-in logs every admin should keep URL: https://azureblog.co.uk/posts/kql-queries-for-entra-sign-in-logs/ Published: 2026-03-11 Tags: Entra ID, Azure, Security > Once sign-in logs flow into Log Analytics, a few queries answer most of the questions you'll get. Copy these into a workbook or saved searches. The Entra portal shows sign-in logs for 30 days with limited filtering. Sending them to a Log Analytics workspace through Diagnostic settings in Entra keeps them for as long as you configure and lets you query them with KQL. Exporting sign-in logs needs Entra ID P1 or P2. [Diagram: Entra sign-in logs land in several tables. Pick the right one.] ## 1. Top sign-in failures ``` SigninLogs | where TimeGenerated > ago(7d) and ResultType != "0" | summarize Count = count() by ResultType, ResultDescription | top 20 by Count ``` ## 2. One user's recent sign-ins ``` SigninLogs | where TimeGenerated > ago(3d) | where UserPrincipalName =~ "jane.doe@contoso.com" | project TimeGenerated, AppDisplayName, ResultType, ResultDescription, IPAddress, Location = tostring(LocationDetails.countryOrRegion), ConditionalAccessStatus | order by TimeGenerated desc ``` ## 3. Sign-ins blocked by Conditional Access ``` SigninLogs | where TimeGenerated > ago(1d) and ConditionalAccessStatus == "failure" | summarize Count = count() by UserPrincipalName, AppDisplayName | order by Count desc ``` ## 4. Successful sign-ins from new countries ``` let known = SigninLogs | where TimeGenerated between (ago(30d) .. ago(1d)) and ResultType == "0" | distinct UserPrincipalName, Country = tostring(LocationDetails.countryOrRegion); SigninLogs | where TimeGenerated > ago(1d) and ResultType == "0" | extend Country = tostring(LocationDetails.countryOrRegion) | join kind=leftanti known on UserPrincipalName, Country | project TimeGenerated, UserPrincipalName, Country, IPAddress, AppDisplayName ``` ## 5. Password spray pattern ``` SigninLogs | where TimeGenerated > ago(1h) and ResultType == "50126" | summarize Users = dcount(UserPrincipalName) by IPAddress | where Users > 10 | order by Users desc ``` 50126 means invalid username or password. One IP failing against many different users is a classic spray. ## 6. Legacy authentication still in use ``` SigninLogs | where TimeGenerated > ago(14d) | where ClientAppUsed !in ("Browser", "Mobile Apps and Desktop clients") | summarize Count = count() by ClientAppUsed, UserPrincipalName, AppDisplayName | order by Count desc ``` Don't forget non-interactive sign-ins: token refreshes and service sign-ins are in the AADNonInteractiveUserSignInLogs table. Some investigations need both. ## 7. Non-interactive sign-ins by app Most sign-in volume is non-interactive: token refreshes by apps the user already signed in to. It's in a separate table and can be large, so only send it if you'll use it. ``` AADNonInteractiveUserSignInLogs | where TimeGenerated > ago(1d) | summarize Count = count(), Failures = countif(ResultType != "0") by AppDisplayName | order by Count desc ``` ## 8. Service principal sign-ins from unexpected IPs ``` AADServicePrincipalSignInLogs | where TimeGenerated > ago(7d) and ResultType == "0" | summarize IPs = make_set(IPAddress, 20), Count = count() by ServicePrincipalName | where array_length(IPs) > 3 | order by Count desc ``` ## Tips for writing your own - Filter on TimeGenerated first. It's the cheapest way to make a query fast. - Use =~ for case-insensitive UPN matches. - Dynamic columns like LocationDetails and DeviceDetail need tostring() before you group by them. - Look up any error code with the AADSTS lookup (https://azureblog.co.uk/tools/aadsts/), or paste a single sign-in into the sign-in log explainer (https://azureblog.co.uk/tools/signin/). More ready-made queries are in the KQL library (https://azureblog.co.uk/tools/kql/). --- # Why Edge suddenly switched language on a whole office URL: https://azureblog.co.uk/posts/edge-switched-language-intune-language-pack/ Published: 2026-03-04 Tags: Intune, Windows > Users in one office reported Edge and LinkedIn appearing in another language. Nobody had touched Edge. The cause was an Intune app assignment. The ticket looked like a browser problem. Users in one regional office said Edge, and sites like LinkedIn, had started showing up in the local language instead of English. Their Edge settings hadn't changed and nobody had pushed a new browser policy. [Diagram: How a language pack ended up changing websites' language.] ## How websites pick a language Most sites choose a language from the Accept-Language header the browser sends. By default, Edge builds that header from the Windows language list. So if Windows gains a new language near the top of that list, websites start following it, even though nothing in the browser changed. ## Finding the cause On an affected machine, the Windows language list under Settings → Time & language → Language & region showed the regional language installed and ranked above English. That pointed away from Edge and towards whatever had installed the language. In Intune, a language pack app had been assigned to that office's devices as Required. Required means Intune installs it automatically on every device in scope, and installing a language pack can also change the user's preferred language order. ## The fix - Change the language pack assignment from Required to Available, so users who want it can install it from Company Portal. - Correct the language order on affected devices, or uninstall the pack where it isn't wanted. - If English must stay first, set it explicitly in policy rather than relying on install order. The Edge setting for the browser's own language is a good extra safeguard. Lesson: "Required" is a strong word in Intune. Anything that changes the user's environment, like languages, fonts or default apps, deserves a pilot group before it goes office-wide. ## Required, Available or Uninstall [Diagram: Intune assignment types for apps.] ## Checking what a browser is sending Ask an affected user to open edge://settings/languages. The order of the list is the order sent to websites. Moving English to the top fixes the symptom on that device straight away, while you fix the assignment centrally. ## Lessons for any Intune change - Pilot user-visible changes with a small group first - Use Available rather than Required unless everyone needs it - Use assignment filters to target exactly the right devices - Note who requested the change, so you can check intent when something odd appears --- # External MFA is GA: third-party MFA without giving up Conditional Access URL: https://azureblog.co.uk/posts/external-mfa-ga/ Published: 2026-02-25 Tags: Entra ID, Security, What's new > Entra ID now officially supports external MFA providers, with Entra still evaluating policy and risk. It's the proper replacement for custom controls. Some organisations have a good reason to use a third-party MFA provider: an existing investment, specialist hardware tokens, or regulatory requirements. Until now, the main way to plug one into Entra was custom controls in Conditional Access, which had real limitations. Most importantly, Entra didn't treat the result as genuine MFA. [Diagram: With external MFA, Entra stays in charge of the policy decision.] External MFA, now generally available, makes a third-party provider a proper authentication method. Entra still evaluates Conditional Access and risk, and the external provider performs the second factor. ## What's better than custom controls - Completing external MFA satisfies an MFA requirement in Conditional Access, like any other method. - It's configured in the authentication methods policy, alongside your other methods. - Sign-in logs show the external method, so troubleshooting isn't guesswork. ## Moving over - Check your provider supports Entra external MFA. - Set it up as a method in the authentication methods policy and target a pilot group. - Update Conditional Access policies that reference the custom control so they require MFA instead. - Retire the custom control once everyone has moved. Worth asking: is the third-party provider still needed? With passkeys now built into Entra, some organisations will find they can retire it entirely. ## Testing before you switch - Pilot with IT users who can tell you exactly what they saw. - Check sign-in logs show the external method in the authentication details. - Test the edge cases: mobile apps, desktop Office apps, and the first sign-in on a new device. - Keep the old custom control in place for everyone else until the pilot is clean. ## Planning for the future External MFA is useful while you depend on a third-party provider. But adding Entra-native passkeys gives you phishing-resistant sign-in with one fewer system to run and pay for. Many organisations will use external MFA as a bridge while they adopt passkeys. **Can users have external MFA and Entra methods at the same time?** Yes. External MFA is one method in the authentication methods policy, so users in scope can also register Entra-native methods such as passkeys. **Does external MFA count as phishing-resistant?** Check how your provider and Entra classify it before using it with authentication strengths that require phishing resistance. Don't assume a hardware token makes the whole flow phishing-resistant. **What happens if the provider is down?** Users who only have the external method can't complete MFA. Keep break-glass accounts excluded and consider a second registered method for critical users. Sources - Microsoft Learn: What's new in Microsoft Entra (https://learn.microsoft.com/en-us/entra/fundamentals/whats-new) --- # Resource locks: a cheap insurance policy against the wrong click URL: https://azureblog.co.uk/posts/azure-resource-locks/ Published: 2026-02-18 Tags: Azure, Governance > A delete lock takes seconds to add and can save a production outage. Here's how locks work, and the ReadOnly gotchas to avoid. RBAC decides who can change a resource. Locks add a second check that applies to everyone, including Owners: the resource can't be deleted, or can't be changed at all, until the lock is removed. ## The two lock types - CanNotDelete (shown as Delete in the portal): the resource can be read and modified, but not deleted. - ReadOnly: the resource can be read, but not modified or deleted. Locks inherit downwards. A lock on a resource group protects everything in it, including resources added later. ``` az lock create --name do-not-delete \ --lock-type CanNotDelete \ --resource-group rg-core-networking \ --notes "Hub networking. Raise a change before removing." ``` [Diagram: What each lock allows on the control plane.] ## Where to use them - Hub virtual networks, ExpressRoute and VPN gateways - DNS zones, including private DNS zones - Key Vaults and Log Analytics workspaces - Recovery Services vaults holding your backups ## Locks protect the control plane, not your data Locks apply to operations through Azure Resource Manager (management.azure.com). They don't apply to data plane operations. That surprises people: - A CanNotDelete lock on a storage account stops the account being deleted, but anyone with data access can still delete blobs in it. Use soft delete, versioning and immutability policies for the data itself. - A lock on a SQL server doesn't stop someone with database permissions dropping a table. - A lock on a Key Vault stops the vault being deleted, but secrets can still be deleted by those with data-plane roles. Soft delete and purge protection cover that. [Diagram: Locks inherit downwards, and the most restrictive lock wins.] ## Be careful with ReadOnly ReadOnly blocks more than you'd expect, because some read-like operations are actually management actions: - Listing storage account keys is a POST operation, so it's blocked, which can break apps and portal views. - Scaling, restarting or reconfiguring services is blocked. - Some backup and update operations fail. In most cases CanNotDelete is the right choice. Keep ReadOnly for resources that truly shouldn't change. Governance tip: only Owners and User Access Administrators can remove locks by default. That makes lock removal a natural point for change control. ## Managing locks at scale ``` # Every lock in the current subscription az lock list --output table # Remove one (needs Microsoft.Authorization/locks/delete) az lock delete --name do-not-delete --resource-group rg-core-networking ``` For many subscriptions, deploy locks as code alongside the resources, in Bicep or Terraform, so a rebuilt environment gets them back automatically. Azure Policy can also audit for resource groups that should be locked but aren't. **Do locks stop Azure Backup or updates?** CanNotDelete rarely gets in the way. ReadOnly can block backup restore points, VM updates and scaling. Test any ReadOnly lock against your operational tasks before relying on it. **Can an Owner still delete a locked resource?** Only by removing the lock first. That's the point: it turns an accidental delete into two deliberate steps, and lock deletion shows up in the activity log. **Should I lock everything?** No. Locks on resources that change often just train people to remove them. Lock the shared foundations that everything depends on. --- # Group-based licensing: finding and fixing assignment errors URL: https://azureblog.co.uk/posts/group-based-licensing-errors/ Published: 2026-02-11 Tags: Entra ID, Microsoft 365 > Group-based licensing is the right way to assign Microsoft 365 licences, until a user silently doesn't get one. Here's where the errors hide. Assigning licences through security groups keeps things tidy: join the group, get the licence. When a new SKU arrives, the usual approach is to mirror the existing setup with a new group. Most of the time it just works. When it doesn't, the user simply ends up without the licence, and nothing tells them why. [Diagram: How a group licence reaches a user, and where it fails.] ## Where errors show up In the Entra admin center, open the licensing group and check its Licenses blade. Groups with problems show a warning, and you can drill into the users affected and the error for each. To find every group with errors across the tenant: ``` Connect-MgGraph -Scopes "Group.Read.All" Get-MgGroup -All -Filter "hasMembersWithLicenseErrors eq true" | Select-Object DisplayName, Id ``` ## The usual causes - Not enough licences. The group has more members than you have seats. Users beyond the limit get nothing. - Conflicting service plans. Some service plans can't be assigned alongside each other. If a user is in two licensing groups with overlapping or conflicting plans, the second assignment can fail. - Missing dependencies. Some add-ons need a base plan to be enabled. If you disabled that plan in the group's licence options, the add-on fails. - No usage location. Users need a usage location set before a licence can be assigned. | Error | Meaning | Fix | CountViolation | Not enough licences | Buy more or remove unused assignments | MutuallyExclusiveViolation | Conflicting service plans | Remove the user from one group, or disable the clashing plan | DependencyViolation | Add-on needs a base plan that's disabled | Enable the required plan in the group's licence options | UsageLocationNotAllowed | No usage location on the user | Set it, ideally from HR data or a default in provisioning | ProhibitedInUsageLocationViolation | Service not available in the user's country | Check the usage location is correct You can check the licence finder at /tools/licences/ (https://azureblog.co.uk/tools/licences/) to see which SKUs include which service plans. ## Moving users between SKUs cleanly - Create the new licensing group and configure its service plans to match the old one. - Test with a small pilot group of users first. - Add users to the new group, check for errors, then remove them from the old one. - Use Reprocess on the group after fixing a problem, so Entra retries the assignments. Tip: keep licensing groups for licensing only. Mixing them with groups used for app access or Conditional Access makes it much harder to see why someone has a licence. [Diagram: A clean SKU migration, with overlap.] ## Reprocessing after a fix Fixing the cause doesn't always clear the error straight away. Reprocess the affected users: ``` Connect-MgGraph -Scopes "User.ReadWrite.All" $g = Get-MgGroup -Filter "displayName eq 'LIC-M365-E5'" Get-MgGroupMember -GroupId $g.Id -All | ForEach-Object { Invoke-MgLicenseUser -UserId $_.Id } ``` **Why does the user have the licence directly and through a group?** Direct and group assignments can coexist. Remove the direct one once the group has applied, so the group is the only thing to manage. **Can a user be in two groups for the same SKU?** Yes. They consume one licence, and the enabled plans are combined across the groups. --- # Azure Policy guardrails every subscription should have URL: https://azureblog.co.uk/posts/azure-policy-allowed-locations-and-guardrails/ Published: 2026-02-04 Tags: Azure, Governance > A handful of built-in Azure Policy assignments stop the most common mistakes before they happen. Start with these at the management group level. Azure Policy evaluates resources against rules and can audit, deny or automatically fix them. You don't need hundreds of policies to get value. A few well-chosen guardrails at the top of your management group hierarchy prevent most of the mess. [Diagram: Assign guardrails high up and they flow down to everything beneath.] ## Start with these built-in policies | Policy | Why | Allowed locations | Keeps resources in the regions you've approved for data residency and support | Allowed locations for resource groups | Stops resource groups (and their metadata) appearing in other regions | Require a tag on resource groups | Enforces ownership and cost-centre tags so every bill has an owner | Inherit a tag from the resource group | Copies tags down automatically, so you don't rely on people tagging every resource | Storage accounts should disable public network access | Closes one of the most common accidental exposures | Configure diagnostic settings | Sends platform logs to your Log Analytics workspace by default ## Roll out with the right effect - Assign with Audit first and review the compliance results. - Fix existing resources, or create exemptions with a reason and an expiry date. - Switch to Deny for prevention policies, and use Modify or DeployIfNotExists with a remediation task for policies that can fix things. ``` # Assign Allowed locations at a management group, UK regions only az policy assignment create \ --name allowed-locations \ --display-name "Allowed locations: UK" \ --scope "/providers/Microsoft.Management/managementGroups/mg-landingzones" \ --policy "e56962a6-4747-49cd-b67b-bf8b01975c4c" \ --params '{ "listOfAllowedLocations": { "value": ["uksouth","ukwest"] } }' ``` Tip: global resources like DNS zones and Front Door use the location "global". Check your allowed list doesn't block them by accident. [Diagram: Choosing an effect for each policy.] ## How evaluation works - New and updated resources are evaluated when they're created or changed. A Deny policy rejects the request there and then. - Existing resources are evaluated by a regular compliance scan, roughly once a day. They aren't deleted or blocked, only marked non-compliant. - New assignments can take up to about 30 minutes to start applying. Don't test a fresh Deny policy and conclude it doesn't work. ``` # Run a compliance scan now rather than waiting az policy state trigger-scan --resource-group rg-app-prod # What's non-compliant at a management group? az policy state summarize --management-group mg-landingzones ``` ## Group them into an initiative Once you have more than a handful of assignments, bundle them into an initiative (policy set). One assignment, one compliance score, and parameters such as the list of allowed regions are set in one place. ## Exemptions done properly - Use the Waiver category for accepted risk and Mitigated when the risk is handled another way - Always add a description that names the owner and the reason - Set an expiry date so the exemption gets reviewed - Scope the exemption as narrowly as possible: a resource, not a subscription **Will Deny break my existing resources?** No. Deny only stops new or updated resources. Existing ones show as non-compliant until you fix or exempt them, but changes to them can be blocked if the change itself doesn't comply. **Why does my deployment fail on a resource group in another region?** The Allowed locations for resource groups policy applies to the group's own location. Create the resource group in an approved region, even if it holds global resources. --- # Converting synced users to cloud-managed: Source of Authority is GA URL: https://azureblog.co.uk/posts/convert-synced-users-to-cloud-source-of-authority/ Published: 2026-01-28 Tags: Entra ID, Hybrid identity, What's new > You can now switch an individual Active Directory-synced user to be managed in the cloud, without deleting and recreating it. A big step towards shrinking on-premises AD. Moving away from on-premises Active Directory has always had an awkward step in the middle. A user synced from AD is mastered in AD. To make them cloud-only, you used to have to break sync, and it often went wrong. [Diagram: What changes when you convert a synced user.] Source of Authority (SOA) conversion for users is now generally available. It switches an individual synced user from AD-managed to cloud-managed, keeping the same Entra object, its access and its history. ## Where it helps - Cloud-first staff. Users who never touch on-premises resources don't need to be mastered in AD. - Shrinking AD gradually. Move users across in waves instead of a big-bang cutover. - Fewer hybrid dependencies. Every user mastered in the cloud is one less thing tied to your sync server. [Diagram: Before and after conversion.] ## Things to check first - On-premises access. If the user still needs file shares, legacy apps or Kerberos resources, check how they'll authenticate after the switch. - Attribute ownership. After conversion, attributes are edited in Entra or by HR-driven provisioning, not in AD. Make sure your joiner/mover/leaver processes know that. - Groups. Group SOA conversion is a related option. Look at which groups can move to the cloud alongside their members. - Pilot. Convert a few IT accounts first and live with them for a while. ## Doing it with Graph Conversion is driven by the user's onPremisesSyncBehavior setting in Microsoft Graph, so you can script waves of users once the pilot is done. Check the current Learn page for the exact permissions and sync client versions required, since your sync engine has to understand the flag. The usual order is: confirm the user is in scope of a sync client that supports the flag, set it on the user, then check the next sync run skips the object without errors. ## A wave plan - Wave 0: IT staff test accounts, live with them for two weeks - Wave 1: cloud-only teams with no on-premises resource access - Update joiner, mover and leaver steps so nobody edits these users in AD - Decide what happens to the old AD object: disable, move to a holding OU, or keep for resource access - Report on converted users monthly, so you know your remaining AD footprint **Does the user notice anything?** Not if they only use cloud resources. Their account, mailbox, group memberships and sign-in stay the same. **Can I switch back?** The setting can be reversed, but plan as if it's one-way and pilot first. Reversing means AD becomes authoritative again and will overwrite cloud changes on the next sync. **What about Exchange hybrid?** Mailbox attributes managed through on-premises Exchange tooling need a plan. Check Microsoft's guidance for Exchange attributes before converting mailbox users at scale. Sources - Microsoft Learn: What's new in Microsoft Entra (https://learn.microsoft.com/en-us/entra/fundamentals/whats-new) --- # Deploy from GitHub Actions to Azure without storing a single secret URL: https://azureblog.co.uk/posts/github-actions-to-azure-without-secrets/ Published: 2026-01-21 Tags: Azure, Entra ID, Security > Workload identity federation lets GitHub Actions sign in to Azure with short-lived tokens instead of a stored client secret. Here's the full setup. The old way to deploy from GitHub to Azure was to create a service principal, generate a client secret and paste it into GitHub as a secret. That secret lasts months or years and works from anywhere if it leaks. [Diagram: Stored secret versus federated credential.] Workload identity federation replaces it. GitHub issues a short-lived OpenID Connect token for each workflow run, and Entra exchanges it for an Azure token, but only if it comes from the repository and branch you trust. ## 1. Create the identity Use an app registration or a user-assigned managed identity. Then grant it the Azure role it needs, scoped as tightly as possible, such as Contributor on one resource group. ## 2. Add a federated credential On the app registration, go to Certificates & secrets → Federated credentials, or the equivalent on the managed identity. Choose the GitHub Actions scenario and enter: - Organization and repository, such as contoso/infra - Entity type: branch, environment, tag or pull request. For deployments, an environment like production is the best choice, because GitHub environments can have their own approval rules. The resulting subject looks like repo:contoso/infra:environment:production, with issuer https://token.actions.githubusercontent.com and audience api://AzureADTokenExchange. [Diagram: The token exchange on every workflow run.] ## 3. Update the workflow Store the client ID, tenant ID and subscription ID as GitHub variables or secrets. They're identifiers, not credentials. The workflow needs permission to request an OIDC token: ``` permissions: id-token: write contents: read jobs: deploy: runs-on: ubuntu-latest environment: production steps: - uses: actions/checkout@v4 - uses: azure/login@v2 with: client-id: ${{ vars.AZURE_CLIENT_ID }} tenant-id: ${{ vars.AZURE_TENANT_ID }} subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }} - run: az group show --name rg-app ``` ## Gotchas - The subject must match exactly. A job using an environment presents the environment subject, not the branch one. - Each federated credential matches one subject. Add more if you deploy from several branches or environments. - Delete the old client secret once the new setup works. ## Troubleshooting | Error mentions | Likely cause | No matching federated identity record | The subject in the token doesn't match. Check branch versus environment versus pull request | Unable to get ACTIONS_ID_TOKEN_REQUEST_URL | The workflow is missing permissions: id-token: write | Authorization failed (Azure) | Sign-in worked, but the identity has no role on the target resource The JWT decoder (https://azureblog.co.uk/tools/jwt/) is handy here: print the GitHub token's claims in a debug step and compare the sub with your federated credential. - Use GitHub environments for production, with required reviewers - One federated credential per environment - Least-privilege role, scoped to a resource group - Delete the old client secret once OIDC works --- # AADSTS75011: when the app insists on how you signed in URL: https://azureblog.co.uk/posts/aadsts75011-requested-authn-context/ Published: 2026-01-14 Tags: Entra ID > Users click a link in an email, land on a SAML app, and get an error page. The fix is not in Entra at all. This one tends to show up the same way every time. Most users sign in fine from the app's home page, but anyone who follows a deep link from an email hits an Entra error page with code AADSTS75011. The message says the authentication method the user signed in with doesn't match the one the application requested. ## What's actually happening In a SAML AuthnRequest, a service provider can include a RequestedAuthnContext element. It tells the identity provider which authentication method it wants, usually something like this: ``` urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport ``` Entra honours that request literally. If the user already has a session that was established with MFA, Windows Hello for Business or a certificate, the method no longer matches PasswordProtectedTransport with an exact comparison, and Entra refuses to issue a token. The deep-link path often builds its request differently from the normal login button, which is why only some routes into the app fail. [Diagram: Why only some routes into the app fail.] ## How to confirm it - Capture the request with the browser's developer tools or a SAML tracer extension. - Base64-decode the SAMLRequest parameter (and inflate it if it was sent by redirect). - Look for RequestedAuthnContext and note the class reference and comparison type. - Check the Entra sign-in log for the failed attempt. The authentication details show which method the user actually used. Paste the captured SAMLRequest into the SAML decoder (https://azureblog.co.uk/tools/saml/). It decodes and inflates it, and flags an exact RequestedAuthnContext automatically. ## Common authentication context values | Class reference (ends with) | Meaning | PasswordProtectedTransport | Password over a protected (TLS) connection | Password | Password, without specifying the transport | X509 | Certificate-based sign-in | unspecified | The app doesn't mind how the user signed in An app asking for PasswordProtectedTransport with exact comparison is effectively saying "only password sign-ins are acceptable", which conflicts with any move to MFA or passwordless. ## The fix lives with the service provider There's no switch in the Enterprise Application to ignore the requested context. The vendor has to change their request. In order of preference: - Remove RequestedAuthnContext entirely and let the IdP's Conditional Access decide how users authenticate. - If they must send it, use Comparison="minimum" so a stronger method still satisfies the request. - Make sure every login route in their app (home page, deep links, mobile) builds the request the same way. Tip: send the vendor the decoded request alongside the sign-in log entry. It turns a vague "SSO is broken" ticket into a one-line config change on their side. ## What to send the vendor Vendors fix this faster when the request is specific. Include: - The decoded AuthnRequest, highlighting RequestedAuthnContext and Comparison - The sign-in log entry showing AADSTS75011 and the method the user signed in with - Which routes fail (deep links) and which work (home page) - The change you're asking for: remove RequestedAuthnContext, or use Comparison="minimum" ## Workarounds while you wait - Tell affected users to open the app from its home page or from My Apps (https://myapps.microsoft.com), where the login flow often doesn't request a context. - Don't weaken Conditional Access to make the error go away. The problem is the app's request, not your policy. --- # Managed identities vs service principals: which should your workload use? URL: https://azureblog.co.uk/posts/managed-identities-vs-service-principals/ Published: 2026-01-07 Tags: Azure, Entra ID, Security > Both let code authenticate to Azure and Microsoft Graph. One needs you to manage secrets; the other doesn't. A simple guide to choosing. Every automation, app and pipeline that talks to Azure needs an identity. There are two common choices, and picking the right one removes a whole class of outages and security risks. [Diagram: Choosing an identity for a workload.] ## Service principals An app registration with a service principal authenticates using a client secret or certificate. It works from anywhere: your laptop, another cloud, a SaaS product. The cost is credential management: secrets expire, get pasted into scripts and leak. ## Managed identities A managed identity is a service principal that Azure manages for you. There are no credentials to store or rotate. The Azure resource gets tokens directly from the platform. - System-assigned: tied to one resource and deleted with it. Good for a single app with its own permissions. - User-assigned: a standalone resource you can attach to several resources. Good when multiple resources need the same access, or when you want the identity to outlive the resource. [Diagram: System-assigned versus user-assigned.] ## How to choose - Code running in Azure (Functions, App Service, VMs, Automation, Container Apps): use a managed identity. - Code running outside Azure that supports OpenID Connect, such as GitHub Actions or another cloud: use workload identity federation, which also needs no secrets. - Only when neither is possible: a service principal with a certificate, stored in Key Vault, with a short lifetime and a named owner. ``` # Give a Function App's system-assigned identity read access to a storage account $principalId = az functionapp identity assign -g rg-app -n func-app --query principalId -o tsv az role assignment create --assignee $principalId \ --role "Storage Blob Data Reader" \ --scope "/subscriptions//resourceGroups/rg-data/providers/Microsoft.Storage/storageAccounts/stdata" ``` Least privilege still applies: no secret doesn't mean no risk. Scope role assignments to the resource, not the subscription. ## How a managed identity gets a token [Diagram: No secret anywhere: Azure vouches for the resource.] In code you rarely call the endpoint directly. The Azure SDKs' DefaultAzureCredential picks up the managed identity automatically, and in PowerShell it's Connect-AzAccount -Identity or Connect-MgGraph -Identity. ## Gotchas - Role assignments can take a few minutes to apply. Retry before assuming the setup is wrong. - Managed identities can be granted Microsoft Graph application permissions, but not through the portal's API permissions blade; use PowerShell or the Graph API. - Deleting a resource deletes its system-assigned identity and its role assignments with it. --- # Named locations: getting IP ranges and countries right in Conditional Access URL: https://azureblog.co.uk/posts/named-locations-in-conditional-access/ Published: 2025-12-17 Tags: Entra ID, Conditional Access > Named locations look simple, but trusted IPs and country blocks are easy to get subtly wrong. What they can and can't do, and how to use them well. Named locations let Conditional Access policies react to where a sign-in comes from. There are two kinds. [Diagram: How a named location is matched.] ## IP ranges A list of public IPv4 and IPv6 ranges, such as your office internet connections or VPN egress. You can mark a range as trusted, which lowers risk in Identity Protection and lets policies include or exclude "all trusted locations". - Use your egress IP addresses: the ones the internet sees, not internal ranges. - Remember IPv6. If your offices have it, sign-ins may come from IPv6 addresses you haven't listed. - Keep the list current when ISPs or VPN providers change. ## Countries and regions Locations can be defined by country, determined either from the IP address or from GPS coordinates via Authenticator. GPS needs the user to share location from the app, so use it carefully. ## Good patterns - Block unexpected countries where you have no staff or business. Keep an exception process for travel. - Don't skip MFA because a user is in the office. It's tempting, but an attacker inside your network, or a compromised device in the office, then gets an easier ride. Use location as a signal, not a pass. - Protect security info registration. Requiring that MFA methods are registered from a trusted location, or with a temporary access pass, makes it harder for an attacker with a stolen password to add their own method. Remember: IP location is approximate, and VPNs and cloud proxies move traffic around. A country block reduces noise; it isn't a strong security boundary on its own. ## Building a country block safely - Export a month of sign-ins and list the countries successful sign-ins came from. You'll find more than you expect: travel, VPNs and cloud services. - Create a named location of the countries you allow, then a policy that blocks everything except that location. An allow-list is easier to reason about than a long block-list. - Exclude break-glass accounts, and decide how travellers request an exception (a temporary group exclusion works well). - Run it in report-only for two weeks before switching it on. ``` SigninLogs | where TimeGenerated > ago(30d) and ResultType == "0" | summarize Users = dcount(UserPrincipalName), SignIns = count() by Country = tostring(LocationDetails.countryOrRegion) | order by SignIns desc ``` ## Watch out for - Mobile networks sometimes route traffic through another country. - Cloud services signing in for users, such as some third-party integrations, appear from their own data centres. - Unknown locations: an IP that can't be placed counts as an unknown country, which you can choose to include or exclude. --- # Authentication strengths: requiring the right kind of MFA URL: https://azureblog.co.uk/posts/authentication-strengths-explained/ Published: 2025-12-10 Tags: Entra ID, Conditional Access, Passkeys > Requiring MFA treats an SMS code and a passkey as equals. Authentication strengths let you say which methods are good enough for which resources. The classic Conditional Access grant control is Require multifactor authentication. It's satisfied by any MFA method the user has, from a text message to a FIDO2 key. Attackers know this, and phishing kits that relay codes and push approvals are now commonplace. Authentication strengths fix this by letting a policy require specific methods. ## The built-in strengths | Strength | What it allows | Multifactor | Any combination that counts as MFA, the same as the classic control | Passwordless MFA | Methods that don't need a password, such as passkeys, Windows Hello for Business and Authenticator phone sign-in | Phishing-resistant MFA | Only methods bound to the real sign-in site: passkeys (FIDO2), Windows Hello for Business and certificate-based authentication You can also create custom strengths, for example allowing only specific security key models by their AAGUID. [Diagram: Each strength is a stricter subset of the one above.] ## Where to use which - Admin roles and admin portals: phishing-resistant. - Sensitive apps such as finance, HR and remote access: phishing-resistant once users have passkeys. - Everything else: multifactor as a baseline, moving to stronger options over time. ## Why phishing-resistant matters Most modern phishing kits sit between the user and the real sign-in page. The user types their password and approves the MFA prompt, and the kit relays both, then steals the session cookie. Codes and push approvals can't tell a real site from a fake one. [Diagram: Why some methods can be relayed and others can't.] Passkeys and Windows Hello are cryptographically tied to the genuine sign-in domain, so a look-alike site gets nothing it can reuse. ## Building a policy - Create a Conditional Access policy targeting a pilot group and the apps you want to protect. - Under Grant, choose Require authentication strength and pick Phishing-resistant MFA. - Run it in report-only mode and look for users who'd fail. - Make sure those users can register a qualifying method, then enforce. ## Roll it out without locking people out - Make sure users have a qualifying method before enforcing. Registration campaigns and temporary access passes help. - Use report-only mode to find users who'd fail. - Watch for guests. Their methods are registered in their home tenant, so check your cross-tenant trust settings before applying strict strengths to them. **Can I combine an authentication strength with 'Require MFA'?** There's no need. The authentication strength already requires MFA of the kind you choose; pick one or the other in a policy. **What about guests?** Guests authenticate in their home tenant. Check your cross-tenant access settings to decide whether to trust their MFA before applying strict strengths to them. --- # Turning on Defender CSPM across a landing zone URL: https://azureblog.co.uk/posts/defender-cspm-at-scale/ Published: 2025-12-03 Tags: Azure, Security > Foundational CSPM is free and already on. Defender CSPM adds attack paths and agentless scanning. Here's how I'd roll it out across many subscriptions. Microsoft Defender for Cloud has two levels of cloud security posture management. Foundational CSPM is free and enabled by default: it gives you the secure score and security recommendations. Defender CSPM is a paid plan that adds features like attack path analysis, the cloud security explorer and agentless scanning. [Diagram: Foundational CSPM is the base. The paid plan builds on it.] ## Plan before you switch it on - Scope. Decide which subscriptions get the paid plan. Production first is a common choice. - Cost. Defender CSPM is billed per billable resource. Check the current pricing page and estimate it against your resource counts before going further. - Extensions. Features like agentless scanning are extensions within the plan, each with its own on/off switch. Decide which you want. - Change control. It's a security improvement, but it's still a billing change across many subscriptions. Raise it through your normal change process. ## One subscription by CLI The Defender CSPM plan is called CloudPosture in the pricing API: ``` az account set --subscription "" az security pricing create --name CloudPosture --tier Standard az security pricing show --name CloudPosture ``` ## Many subscriptions with Azure Policy For a landing zone, assign the built-in policy that enables Defender CSPM at the management group. Search the policy definitions for "Defender CSPM" to find it. A policy with a DeployIfNotExists effect means new subscriptions pick up the plan automatically, so nothing slips through. - Assign the policy at the right management group. - Run a remediation task to apply it to existing subscriptions. - Check the Environment settings page in Defender for Cloud to confirm each subscription shows the plan as on. After rollout: give agentless scanning a day or so to complete its first pass before judging the results. Then start with the attack paths, which show which recommendations actually matter most. [Diagram: How a DeployIfNotExists policy keeps every subscription covered.] The assignment needs a managed identity with rights to set pricing on subscriptions, and existing subscriptions need a remediation task. New ones are covered automatically. ## Getting value in the first month - Attack paths. Start with the paths marked critical. They join several weaknesses into a real route to something valuable, which makes them easier to prioritise than a long list of recommendations. - Cloud security explorer. Use the built-in templates, such as internet-exposed VMs with high-severity vulnerabilities, to answer questions that used to need a spreadsheet. - Governance rules. Assign owners and due dates to recommendations automatically, so findings go to the team that can fix them. ## Checking coverage ``` // Azure Resource Graph: Defender CSPM status per subscription securityresources | where type == "microsoft.security/pricings" and name == "CloudPosture" | project subscriptionId, tier = tostring(properties.pricingTier) | order by tier asc ``` **Do I lose anything by staying on foundational CSPM?** You keep secure score and recommendations. You miss the context features, such as attack paths and the explorer, that help you decide what to fix first. **Is Defender CSPM the same as Defender for Servers?** No. CSPM is about posture across your cloud estate. Workload plans like Defender for Servers protect specific resource types and are billed separately. --- # Test Conditional Access safely with report-only mode and What If URL: https://azureblog.co.uk/posts/conditional-access-report-only-and-what-if/ Published: 2025-11-26 Tags: Entra ID, Conditional Access > Most Conditional Access outages come from a policy that did something nobody expected. Two built-in tools let you see exactly what a policy would do before it does it. Conditional Access is powerful precisely because it can block anyone from anything. That's also why a careless change can lock out a whole organisation. Two tools take most of the risk away. ## Report-only mode Set a policy's state to Report-only and Entra evaluates it on every sign-in without enforcing it. The result is recorded in the sign-in logs on the Report-only tab: would it have applied, and would the user have passed or failed? Run new policies in report-only for at least a week, so you see a full working cycle including remote work, mobile devices and service accounts. [Diagram: The three policy states.] ## Reviewing the impact The Conditional Access insights and reporting workbook summarises report-only results across all sign-ins. With logs in Log Analytics, you can also query it directly: ``` SigninLogs | where TimeGenerated > ago(7d) | mv-expand ConditionalAccessPolicies | where ConditionalAccessPolicies.displayName == "Require compliant device" | where ConditionalAccessPolicies.result == "reportOnlyFailure" | summarize Failures = count() by UserPrincipalName, AppDisplayName | order by Failures desc ``` Every reportOnlyFailure is someone who would have been blocked. Work through the list before you switch the policy on. ## The What If tool What If answers a specific question: if this user signed in to this app, from this platform and location, which policies would apply? You'll find it on the Conditional Access Policies page. It's ideal for troubleshooting a single user's ticket and for checking your exclusions are doing what you expect. ## Reading report-only results | Result | What it means | reportOnlySuccess | The user would have met the policy's requirements | reportOnlyFailure | The user would have been blocked. Investigate before enforcing | reportOnlyInterrupted | The user would have been prompted, for example for MFA | reportOnlyNotApplied | The policy's conditions didn't match this sign-in One known quirk: Microsoft notes that report-only policies requiring a compliant device can still prompt users on macOS, iOS and Android to pick a device certificate. Test on those platforms before a wide report-only rollout. ## A safe rollout pattern - Create the policy in report-only. - Review the results after a week and fix the gaps. - Enable it for a pilot group, then everyone. - Keep break-glass accounts excluded throughout. [Diagram: A typical timeline for a new policy.] Try the sign-in log explainer (https://azureblog.co.uk/tools/signin/) when reviewing individual sign-ins: paste the exported JSON to see which policies applied and why. --- # SCIM provisioning when every target is its own app URL: https://azureblog.co.uk/posts/scim-one-app-per-library/ Published: 2025-11-19 Tags: Entra ID > Some SaaS platforms need a separate Enterprise App for each instance or library. A few habits keep that manageable. Entra's SCIM provisioning works per Enterprise Application. When a vendor splits their platform into several instances or libraries, each one gets its own app, its own token, its own attribute mappings and its own provisioning cycle. With three or four of those, small differences creep in fast. [Diagram: One Entra tenant provisioning into several targets, each through its own Enterprise App.] ## Habits that help - Name apps consistently. A pattern like Vendor - Library - Region makes the list sortable and obvious to the next engineer. - Assign groups, not users. One security group per app keeps scope visible and auditable. - Document the mappings once. Keep a single table of source attribute, target attribute and any expression, then check each app against it. - Use Provision on demand to test a single user before you start the full cycle. - Watch the provisioning logs, not just the app status. A cycle can report success while quietly skipping users with a missing attribute. ## How a provisioning cycle works [Diagram: What happens in each cycle.] The first cycle processes everyone in scope and can take a while. Later cycles only process changes, so they're much quicker. If you change attribute mappings, Entra may need another full cycle. ## Troubleshooting checklist - User not created: check they're assigned to the app (directly or via a group) and that the scope is set to assigned users only. - "Skipped" in the logs: usually a scoping filter or a missing required attribute. - Duplicates in the target: the matching attribute differs between Entra and the app. Fix the matching rule before re-running. - Authentication errors: the secret token or tenant URL is wrong or has expired. Test the connection on the Provisioning blade. ## A useful expression Many targets want a username without the domain. This mapping takes the part of the UPN before the @: ``` Replace([userPrincipalName], , "(?[^@]+)@.*", "user", "${user}", , ) ``` Before you go live: agree with the vendor what happens on deprovisioning. "Disable" and "delete" mean very different things when a user owns content in the target system. Use Provision on demand for one user whenever you change a mapping. It shows each step of the cycle for that user, which is far quicker than waiting for the next scheduled run. --- # Break-glass accounts done right URL: https://azureblog.co.uk/posts/break-glass-accounts-done-right/ Published: 2025-11-12 Tags: Entra ID, Security, Conditional Access > Emergency access accounts are the one thing you hope never to use and must never get wrong. A practical checklist for setting them up and keeping them safe. If a Conditional Access policy locks everyone out, your MFA provider has an outage, or your federation service goes down, you need a way back in. That's what emergency access, or "break-glass", accounts are for. [Diagram: What emergency accounts must and mustn't depend on.] ## The setup - Two accounts, so one can be used while the other is investigated or has its credentials rotated. - Cloud-only, using the .onmicrosoft.com domain. They mustn't depend on on-premises AD, sync or federation. - Permanent Global Administrator, not PIM eligible. PIM is one more thing that could fail during an emergency. - Not tied to a person. No mailbox you rely on, no personal phone number. ## Authentication Microsoft now enforces MFA for sign-ins to Azure and the admin portals, and that includes emergency accounts. The best option is phishing-resistant: FIDO2 security keys, registered to each account and stored securely in separate physical locations. Keep a backup key for each. ## Conditional Access Exclude at least one break-glass account from every Conditional Access policy, so a broken policy can't lock it out. The easiest way is a dedicated exclusion group used consistently across policies. Review the group's membership regularly, because it's a high-value target. ## Monitoring These accounts should almost never sign in, so any sign-in is worth an alert. With sign-in logs in Log Analytics: ``` SigninLogs | where UserPrincipalName in~ ("bg-admin1@contoso.onmicrosoft.com", "bg-admin2@contoso.onmicrosoft.com") | project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType ``` Turn that into an alert rule that notifies the security team immediately. ## Test it Every few months, sign in with each account, confirm the key works and the alert fires, and record the test. An emergency account nobody has tested isn't an emergency account. ## Writing the procedure An emergency is the worst time to work out the steps. Write a one-page procedure and store it where it can be found when Entra is unavailable, such as a sealed envelope or a password manager outside your tenant. Include: - Who is allowed to use the accounts and who must approve it. - Where the keys are kept and who holds access to each location. - What to do first once signed in, for example disabling the broken Conditional Access policy. - Who to tell afterwards, and how to reset and re-secure the account. [Diagram: What a well-run break-glass sign-in looks like.] --- # Activate PIM roles from PowerShell with Microsoft Graph URL: https://azureblog.co.uk/posts/activate-pim-roles-with-powershell/ Published: 2025-11-05 Tags: Entra ID, PowerShell, Governance > The portal is fine for occasional use, but if you activate roles every day, a few lines of Graph PowerShell are faster. Here's how to list eligible roles and activate one. Privileged Identity Management is the right way to handle admin roles: nobody holds them permanently, and every elevation is time-boxed and justified. The downside is clicks. If you activate roles several times a day, scripting it with the Microsoft Graph PowerShell SDK saves real time. [Diagram: What happens when you activate a role from PowerShell.] ## Connect with the right scopes ``` Connect-MgGraph -Scopes "RoleEligibilitySchedule.Read.Directory", "RoleAssignmentSchedule.ReadWrite.Directory" $me = Get-MgUser -UserId (Get-MgContext).Account ``` ## List your eligible roles ``` $eligible = Get-MgRoleManagementDirectoryRoleEligibilityScheduleInstance -Filter "principalId eq '$($me.Id)'" -ExpandProperty RoleDefinition $eligible | Select-Object @{n="Role";e={$_.RoleDefinition.DisplayName}}, DirectoryScopeId, EndDateTime ``` ## Activate one Activation is a role assignment schedule request with the action selfActivate. The duration uses ISO 8601 format, so PT2H means two hours: ``` $role = $eligible | Where-Object { $_.RoleDefinition.DisplayName -eq "Exchange Administrator" } $params = @{ Action = "selfActivate" PrincipalId = $me.Id RoleDefinitionId = $role.RoleDefinitionId DirectoryScopeId = $role.DirectoryScopeId Justification = "Investigating mail flow issue" ScheduleInfo = @{ StartDateTime = Get-Date Expiration = @{ Type = "AfterDuration"; Duration = "PT2H" } } } New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest -BodyParameter $params ``` ## Check the result, extend or end early The request returns a status straight away. Provisioned means the role is active. PendingApproval means the role's PIM settings require an approver, and nothing happens until they respond. ``` # Requests you've made, newest first Get-MgRoleManagementDirectoryRoleAssignmentScheduleRequest -Filter "principalId eq '$($me.Id)'" | Sort-Object CreatedDateTime -Descending | Select-Object -First 5 Action, Status, RoleDefinitionId, CreatedDateTime # Finished early? Deactivate rather than leave it running $params.Action = "selfDeactivate" $params.Remove("ScheduleInfo"); $params.Remove("Justification") New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest -BodyParameter $params ``` Deactivating when you're done is good practice. It shortens the window in which a stolen session could use the role, and it shows up in the audit log as a deliberate action. ## Wrap it in a function Once it works, put it in your PowerShell profile so activation becomes one command: ``` function Enable-PimRole { param([Parameter(Mandatory)][string]$Role, [string]$Reason = "Planned admin work", [int]$Hours = 1) $me = Get-MgUser -UserId (Get-MgContext).Account $r = Get-MgRoleManagementDirectoryRoleEligibilityScheduleInstance -Filter "principalId eq '$($me.Id)'" -ExpandProperty RoleDefinition | Where-Object { $_.RoleDefinition.DisplayName -eq $Role } if (-not $r) { throw "Not eligible for $Role" } New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest -BodyParameter @{ Action = "selfActivate"; PrincipalId = $me.Id RoleDefinitionId = $r.RoleDefinitionId; DirectoryScopeId = $r.DirectoryScopeId Justification = $Reason ScheduleInfo = @{ StartDateTime = Get-Date; Expiration = @{ Type = "AfterDuration"; Duration = "PT$($Hours)H" } } } } Enable-PimRole -Role "Intune Administrator" -Reason "Deploying compliance policy" -Hours 2 ``` ## Things that trip people up - Role settings still apply. If the role needs approval, a ticket number or a shorter maximum duration, the request fails with an error that says so. Read it rather than retrying. - MFA and authentication context. If the role requires MFA or a Conditional Access authentication context on activation, your Graph session must satisfy it. You may need to reconnect so you're prompted. - Propagation. An activated role can take a minute or two to take effect in some admin portals. Sign out and back in if a portal doesn't see it. - Deactivate when done. Use the action selfDeactivate with the same role and scope to end the activation early. Tip: wrap this in a small function or a simple GUI and share it with your team. The easier activation is, the less people push back on PIM. | Error or symptom | What it usually means | Activation rejected for duration | You asked for longer than the role's maximum activation duration in PIM settings. Ask for less. | Justification or ticket required | The role settings require them. Add Justification or TicketInfo to the request. | Authentication context or ACRS validation error | The role requires a Conditional Access authentication context. Activate in the portal, or reconnect so your token satisfies that context. See PIM with authentication context (https://azureblog.co.uk/posts/pim-activation-conditional-access-context/). | Role active but the portal still says no | Your existing token predates the activation. Sign out and back in, or wait a few minutes. | Insufficient privileges on the request | Your Graph session lacks RoleAssignmentSchedule.ReadWrite.Directory. Reconnect with the scope. **Can I use this for Azure resource roles too?** Not with these cmdlets. Azure resource roles use the Azure PIM APIs in Az PowerShell, such as New-AzRoleAssignmentScheduleRequest, with the same idea of an eligible schedule and a self-activation request. **Does scripting bypass MFA or approval?** No. The request is checked against the same role settings as the portal. If the role needs approval, the request waits for it. **Can a service principal activate a role?** PIM is designed for people. Workload identities should hold only the narrow permissions they need, granted directly, and be monitored instead. --- # Find expiring app secrets and certificates before they bite URL: https://azureblog.co.uk/posts/find-expiring-app-secrets-graph/ Published: 2025-10-29 Tags: Entra ID, PowerShell > Expired client secrets cause some of the most avoidable outages in Entra. A short Graph script shows what's about to expire across the tenant. App registrations authenticate with client secrets or certificates, and both expire. When one does, an integration quietly stops working, often on a Monday morning. Entra doesn't email the app owner by default, so you need your own early warning. [Diagram: Three ways an app can authenticate, from most to least maintenance.] ## The script This lists every secret and certificate on every app registration, with the days remaining, sorted so the most urgent are first: ``` Connect-MgGraph -Scopes "Application.Read.All" $days = 60 $now = Get-Date Get-MgApplication -All -Property DisplayName,AppId,PasswordCredentials,KeyCredentials | ForEach-Object { $app = $_ $creds = @( $app.PasswordCredentials | ForEach-Object { [pscustomobject]@{ Type="Secret"; Name=$_.DisplayName; End=$_.EndDateTime } } $app.KeyCredentials | ForEach-Object { [pscustomobject]@{ Type="Certificate"; Name=$_.DisplayName; End=$_.EndDateTime } } ) foreach ($c in $creds) { [pscustomobject]@{ App = $app.DisplayName AppId = $app.AppId Type = $c.Type Name = $c.Name Expires = $c.End DaysLeft = [int]($c.End - $now).TotalDays } } } | Where-Object DaysLeft -le $days | Sort-Object DaysLeft | Format-Table -AutoSize ``` Negative DaysLeft values are already expired. Those are worth a look too: an expired secret that nobody noticed might mean the app is no longer used and can be cleaned up. ## Making it useful - Export it. Swap Format-Table for Export-Csv and share it with app owners. - Run it on a schedule. An Azure Automation runbook with a managed identity granted Application.Read.All can run it weekly and email the results. - Set owners. Every app registration should have at least two owners, so there's always someone to chase. - Prefer certificates or managed identities. Shorter secret lifetimes are safer, but managed identities remove the problem entirely for Azure-hosted workloads. ## Running it weekly with Azure Automation - Create an Automation account with a system-assigned managed identity. - Grant the identity the Microsoft Graph application permission Application.Read.All. - Add the Microsoft.Graph.Authentication and Microsoft.Graph.Applications modules to the account. - Create a PowerShell runbook with the script, replacing Connect-MgGraph -Scopes … with Connect-MgGraph -Identity. - Schedule it weekly and send the results to a shared mailbox or Teams channel. [Diagram: The weekly check, unattended.] ## What to do with the list - Expiring soon: contact the owner and agree a rotation date. - Already expired: check whether the app is still used before renewing; it may be safe to delete. - No owner: find one before the next expiry, or plan to retire the app. --- # Rolling a SAML signing certificate without an outage URL: https://azureblog.co.uk/posts/saml-certificate-rollover/ Published: 2025-10-22 Tags: Entra ID > Entra SAML signing certificates expire after three years by default. Here's the cutover plan I use so nobody notices the change. Every SAML Enterprise Application in Entra signs its tokens with a certificate. When that certificate expires, sign-ins stop. The good news is that Entra lets you stage a new certificate before you switch to it, so the whole thing can be done with zero downtime if the vendor cooperates. [Diagram: A calm rollover, planned around the expiry date.] ## Before the change - Check who receives expiry notifications under SAML Certificates → Notification email. Add a shared mailbox, not just one person. - Find out whether the vendor's side supports more than one trusted certificate at a time. This decides the whole plan. - Book a short window with the vendor contact if they don't. ## The rollover - In the app's Single sign-on blade, open SAML Certificates and choose Edit → New Certificate. Save it but leave it inactive. - Download the new certificate (Base64) or the federation metadata XML and send it to the vendor. - If the vendor supports two certificates: they add the new one alongside the old. You make the new one active whenever you like, then they remove the old one. - If they support only one: agree a time, make the new certificate active in Entra, and have them swap theirs at the same moment. Test immediately. - Test with a pilot user in a private browser window, then confirm a clean entry in the sign-in logs. [Diagram: Your plan depends on what the vendor supports.] ## Quick inventory with Graph To see what's coming up across the tenant, this lists service principals with SAML signing keys and their expiry dates: ``` Connect-MgGraph -Scopes "Application.Read.All" Get-MgServicePrincipal -All -Property DisplayName,KeyCredentials,PreferredSingleSignOnMode | Where-Object PreferredSingleSignOnMode -eq "saml" | ForEach-Object { foreach ($k in $_.KeyCredentials | Where-Object Usage -eq "Verify") { [pscustomobject]@{ App = $_.DisplayName Expires = $k.EndDateTime DaysLeft = [int]($k.EndDateTime - (Get-Date)).TotalDays } } } | Sort-Object DaysLeft | Format-Table ``` Note: the signing certificate shows up on the service principal as a Verify key credential alongside a matching Sign private key. Filtering on Verify gives one row per certificate. ## What breaks if you miss it When the active signing certificate expires, every SAML sign-in to that app fails. The vendor's error usually mentions an invalid signature, and users see a vendor error page rather than a Microsoft one, which can send troubleshooting down the wrong path. If an app suddenly fails for everyone, check the certificate first. ## Make expiry boring - Add a shared mailbox as the certificate notification address on every SAML app - Keep a list of SAML apps, their vendor contacts and whether they support two certificates - Run the inventory script monthly, or schedule it in Azure Automation - Note each app's expiry date in your team calendar **Does creating a new certificate break anything?** No. A new certificate stays inactive until you make it active, so you can create it and share it with the vendor safely. **Can I set a longer lifetime?** You can choose the expiry when creating the certificate. Longer lifetimes mean fewer rollovers but a longer window if a key is ever compromised; three years is the default. --- # Temporary Access Pass: onboarding users without a password URL: https://azureblog.co.uk/posts/temporary-access-pass-onboarding/ Published: 2025-10-15 · Updated: 2026-10-09 Tags: Entra ID, Passkeys, Security > A Temporary Access Pass lets a new starter, or someone who's lost their phone, sign in once and set up a passkey or Authenticator. No temporary passwords sent by email. The weakest moment in most identity setups is day one. A new starter gets a temporary password, often by email or text, and has to register MFA before they've proven who they are. Lost-phone recovery has the same problem in reverse. A Temporary Access Pass (TAP) fixes both. ## What it is A TAP is a time-limited passcode issued by an admin. It satisfies strong authentication requirements, so the user can sign in and register passwordless methods such as a passkey, Windows Hello for Business or Microsoft Authenticator. [Diagram: A new starter's first day with a Temporary Access Pass.] ## Turn it on In the Entra admin center, go to Entra ID → Authentication methods → Policies → Temporary Access Pass. Enable it for the right groups and set: - Lifetime: keep it short, such as one hour for onboarding. - One-time use: require it, so the pass can't be reused. - Length: the default is fine for most organisations. ## Issue one with PowerShell ``` Connect-MgGraph -Scopes "UserAuthenticationMethod.ReadWrite.All" $tap = New-MgUserAuthenticationTemporaryAccessPassMethod -UserId "new.starter@contoso.com" -BodyParameter @{ lifetimeInMinutes = 60 isUsableOnce = $true } $tap.TemporaryAccessPass ``` ## Good practice - Verify identity first. A TAP is only as strong as the check done before issuing it: a video call with ID, a manager confirming in person, or HR onboarding data. - Deliver it separately. Read it out on the call or hand it over in person rather than emailing it. - Pair with a registration campaign so users are guided straight to a passkey. - Limit who can issue. Authentication Administrators can issue TAPs for users without admin roles; admins need a Privileged Authentication Administrator. Nobody can issue a TAP for themselves. Bonus: TAP works during Entra join, including Windows Autopilot, so a new starter can join a laptop and set up Windows Hello without ever having a password. On a device that is already joined, or hybrid joined, the user has to sign in with another method first. ## Common scenarios | Scenario | Suggested settings | New starter | One-time use, 1 to 8 hours, issued on day one after an identity check | Lost or new phone | One-time use, 1 hour, after verifying the user by video or in person | Windows Autopilot setup | Multi-use for about an hour, or be ready to issue a second one-time pass: a one-time pass only allows 10 minutes to register a passwordless method, and setup often takes longer | Locked-out admin | Issued only by a Privileged Authentication Administrator ## Troubleshooting - The user isn't offered the TAP option: check the Temporary Access Pass policy targets a group they're in. - "Pass has expired": the lifetime runs from the pass's start time (when it was created, unless you set a later start), not from first use. Issue a new one. Each user can only have one TAP at a time. - One-time pass used, but registration didn't finish: after signing in with a one-time pass, the user has 10 minutes to register a passkey or phone sign-in. Issue another pass. - Can't issue a pass for an admin: that needs the Privileged Authentication Administrator role. - TAP policy enabled for the right groups - One-time use required - Identity verification steps written down for the service desk - Registration campaign set up to steer users to passkeys - Audit log alert on TAP creation for admin accounts Sources - Microsoft Learn: Configure a Temporary Access Pass (https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-temporary-access-pass)