The Future of Identity: Self-Service Account Recovery (Preview) in Microsoft Entra
In the modern enterprise, the "Help Desk" is paradoxically both a vital resource and a massive security liability. As organizations move toward phishing-resistant, passwordless environments using passkeys and FIDO2 tokens, a critical question remains: What happens when a user loses their only authentication device? Historically, this required a phone call to a support agent. However, in an era of sophisticated social engineering and AI-generated deepfakes, a human agent is often the easiest point of entry for an attacker. Microsoft Entra’s new Self-Service Account Recovery solves this by replacing manual verification with high-assurance, automated identity proofing. The Fatal Flaw in Traditional Recovery Most organizations currently rely on one of two methods for recovery, both of which have significant drawbacks: Self-Service Password Reset (SSPR): Often relies on "weak" factors like SMS codes or security questions. These are easily intercepted or guessed and don't help a user who is trying to move away from passwords entirely. The Help Desk: Requires an agent to "vouch" for a user. Attackers can impersonate employees, use voice-cloning technology, or provide leaked personal information to trick an agent into issuing a Temporary Access Pass (TAP). The new Entra flow removes the human element from the validation process, ensuring that the person regaining access is exactly who they claim to be. How the New Recovery Flow Works: The recovery process is built on the concept of "identity proofing," utilizing government-issued documents and biometric liveness checks. Integration with Verification Partners Microsoft doesn’t store your passport or driver's license. Instead, Entra integrates with specialized Third-Party Identity Verification providers (such as True Credential, IDEMIA, AU10TIX). These services are experts in forensic document analysis. The Verification Process When a user begins a recovery, they are redirected to the partner service. The process typically involves: Document Capture: The user takes a photo of a government ID (Passport, Driver’s License, etc.). Forensic Analysis: The service checks for security features like holograms, fonts, and watermarks to ensure the ID is genuine. Liveness Check: The user takes a "selfie" or video. The system uses "Face Check" technology projecting specific light patterns or colors on the user’s face to ensure it is a live person and not a photo, video, or deepfake. Issuance of a Verified ID Once the third party confirms the user's identity, Microsoft Entra issues Verified ID. This is a decentralized, digital credential that sits in the user's Microsoft Authenticator app. It serves as digital proof of their identity that Entra can trust. The Final Handshake: Face Check To bridge the gap between the digital credential and the person at the keyboard, Entra performs a Face Check. It compares the live user's face against the photo contained within the Verified ID. If they match, Entra considers the identity "proven." Bootstrapping the New Device Once verified, Entra automatically issues a Temporary Access Pass (TAP). This allows the user to log in and immediately register their new device, passkey, or Authenticator app, effectively "bootstrapping" their new secure environment without ever speaking to a human. Strategic Advantages for IT Leaders Zero Trust Maturity: This process fulfills the Zero Trust requirement of "explicit verification" even during the recovery phase. Scalability: By automating the most time-consuming part of help desk tickets identity verification IT teams can focus on more complex tasks. Phishing Resistance: Because the recovery is tied to physical ID and biometrics, there is no "code" for an attacker to phish. Global Compliance: Leveraging government-issued IDs allows organizations to meet high-bar regulatory requirements for identity assurance (such as NIST IAL2). Deployment and Prerequisites To implement this, administrators need to ensure a few things are in place: Verified ID Setup: You must configure Microsoft Entra Verified ID within your tenant. Matching Logic: Entra uses attributes like First Name and Last Name to match the Verified ID to the user account. Ensuring your HR data is clean and synchronized is essential. License & Costs: While the recovery flow is a feature of Entra, the verification partners and the Face Check service (typically a per-check fee) must be provisioned through the Microsoft Security Store. Conclusion The transition to a passwordless world is incomplete if the "back door" (recovery) remains open and insecure. By integrating government-grade identity verification directly into the login flow, Microsoft Entra provides the final piece of the puzzle: a recovery method that is as secure as the primary login itself.
eDiscovery - Issues exploring groups & users related to a hybrid data source
Hi all, first time posting - unusually I could find nothing out there that helped. I work in an organisation has an on-premises domain which syncs to our tenant. I don't manage the domain or the sync, but I'm assured that the settings are vanilla and there are no errors being logged. 99% of our users are hybrid. The tenant is shared across multiple legal entities, so I'm using eDiscovery to fulfil our GDPR subject access requests The issue I am hitting is straightforward. in eDiscovery searches with hybrid users as the data source, I cannot add related objects (manager, direct reports, groups the user is in). The properties are present in Entra, but not visible to Purview, so I'm not investigating sync errors at the moment. For cloud objects, I can see manager, teams, etc. and it works fine. Does anyone have any insights they can share on the "explore and add" mechanics in eDiscovery search data sources? I'm drawing a complete blank on this one. Where should I be looking?Conditional Access for Agent Identities in Microsoft Entra
AI agents are rapidly becoming part of everyday enterprise operations summarizing incidents, analyzing logs, orchestrating workflows, or even acting as digital colleagues. As organizations adopt these intelligent automations, securing them becomes just as important as securing human identities. Microsoft Entra introduces Agent Identities and extends Conditional Access to them but with very limited controls compared to traditional users and workload identities. This blog breaks down what Agent Identities are, how Conditional Access applies to them, and what are current limitations. What Exactly Are Agent Identities? Microsoft Entra now supports a new identity type designed specifically for AI systems: Agent Identity – like an app/service principal but specialized for AI Agent User – an identity that behaves more like a human user Agent Blueprint – a template used to create agent identities This model exists because AI systems behave differently than humans or applications: they can act autonomously, operate continuously, and make decisions without user input. AI-driven automation must be governed and that’s where Conditional Access comes in. Conditional Access for Agents, but with Important Limitations Today, Conditional Access for agent identities is purposely minimal. Microsoft clearly states: Conditional Access applies only when: An agent identity requests a token An agent user requests a token It does NOT apply when: A blueprint acquires a token to create identities An agent performs intermediate token exchange What Controls Are Actually Available Today? ✔ Supported Today Category Supported? Details Identity Targeting ✔ Yes You can include/exclude agent identities & agent users Block Access ✔ Yes This is the only Grant control currently available Agent Risk (Preview) ✔ Yes Early stage risk evaluation Sign-in evaluation ✔ Yes Token acquisition governed by CA ❌NOT Supported Today These CA controls do not apply to Agent Identities: MFA Authentication strength Device compliance Approved client apps App protection policies Session controls User sign-in frequency Terms of Use Location conditions (network/device-based) Client apps (legacy/modern access) Why? Because agents do not perform interactive authentication and do not use device signals or session context like humans. Their authentication is purely machine‑driven. How Conditional Access Works for Agents When an agent identity (or agent user) requests a token, Microsoft Entra: Identifies the requesting agent Checks CA policy assignments Evaluates any agent-risk conditions Allow/Blocks token issuance if conditions meet That’s it. No MFA prompt. No device check. No authentication strength evaluation. This makes CA for agents fundamentally different from CA for humans. Why Is Conditional Access So Limited for Agents? Two major reasons: Agents cannot satisfy user-based controls AI agents cannot: Perform MFA Use biometrics Run on compliant devices Follow session prompts These are human-driven processes. Agents authenticate via secure credential flows They use: Client credentials Federated identity credentials Token exchange flows So CA is limited to identity-level allow/block and risk-based token decisions. Practical Use Cases (Given Today’s Limitations) Even with limited controls, CA for agents is still important. Stop compromised agents from continuing to operate If Microsoft Entra detects high agent risk: CA can block token issuance This halts the agent’s ability to act immediately Enforce separation of duties for AI agents Even though you cannot apply MFA or auth strength, you can: Separate agents into “allowed” vs “blocked” groups Apply different CA rules per department or system Prevent AI sprawl Large enterprises may generate hundreds of AI agents. CA gives central admin control: Only approved, vetted agents can operate Others are blocked at token-request time Why Agent Blueprints Cannot Be Governed by CA Blueprints are templates, not active identities. Blueprint token flows are system-level operations, not access attempts. Therefore: ❌ No CA evaluation ❌ No controls applied ❌ Not counted as agent activity Only actual agent identities are governed by CA. What the Future Might Include Microsoft hints the capabilities will expand: Agent risk scoring Agent behaviour analytics More granularity in CA for agents Additional grant controls Policy scoping at task or capability level But as of today, CA for agents remains intentionally constrained to allow safe onboarding of the new identity type without accidental disruption. Final Summary Conditional Access for Agent Identities is currently a lightweight enforcement mechanism designed to block unauthorized or risky agents, not a full policy suite like we have for human users. ✔ What it does: Controls whether an agent identity can acquire a token Allows blocking specific agents Implements early agent‑risk logic Applies Zero Trust principles at the identity perimeter ❌ What it does not do: Enforce MFA Enforce authentication strength Enforce device or location conditions Apply session controls Govern blueprints As organizations adopt more autonomous agents, this foundational layer keeps AI identities visible and controllable and sets the stage for richer governance in the future.Platform SSO for macOS
Introduction As organizations accelerate their journey to passwordless authentication, Microsoft’s Platform SSO for macOS offers a seamless, secure, and user-friendly experience for device and application sign-in. Built on Apple’s SSO framework and tightly integrated with Microsoft Entra ID, Platform SSO empowers users to leverage modern authentication methods Touch ID, smart cards, and passkeys across their macOS devices, enterprise apps, and browsers. In this blog, we’ll walk through the essentials of Platform SSO, supported authentication methods, configuration steps, and best practices for deployment in enterprise environments. What is Platform SSO for macOS? Platform SSO is a Microsoft feature for macOS (13+) that leverages Apple’s SSO framework to enable single sign-on using Entra ID credentials. Users benefit from passwordless authentication, enhanced security, and a consistent experience whether logging into their device, enterprise applications, or web browsers. Key highlights: Passwordless sign-in: Use Touch ID (Secure Enclave), smart cards, or passwords for device and app authentication. Enterprise SSO plug-in: Activated for both application and browser-based sign-in, ensuring centralized identity management. No agent required: Utilizes built-in macOS platform capabilities for easy deployment and management. Authentication Methods Supported by Platform SSO Platform SSO supports three primary authentication methods on macOS: Feature Secure Enclave Smart Card Password Passwordless (phishing resistant) ✅ ✅ ❌ Touch ID supported for unlock ✅ ✅ ✅ Can be used as passkey ✅ ❌ ❌ Local Mac password synced with Entra ID ❌ ❌ ✅ Supported on macOS 14.x+ ✅ ✅ ✅ MFA mandatory for setup ✅ ✅ ❌ Secure Enclave: Recommended for most users, Secure Enclave uses hardware-bound cryptographic keys for app and web sign-ins, enabling passwordless and phishing-resistant MFA. After a reboot, users enter their local password once, then Touch ID can be used for subsequent unlocks. The device receives a hardware-backed Primary Refresh Token (PRT) for device-wide SSO. Smart Card: Ideal for high-security or compliance-driven environments, Smart Card authentication provides complete passwordless sign-in and unlock. After sign-in, the device receives a PRT and Workplace Join (WPJ) certificate for seamless SSO to Microsoft 365, Safari, and Entra-protected apps. Password: Users sign in with their Entra ID password, which syncs to the local account for SSO across apps. Intune password policies ensure alignment with Entra ID password rules, preventing sync or sign-in issues. How Platform SSO Works When a Mac device joins a Microsoft Entra ID tenant, it receives a hardware-bound WPJ certificate accessible only by the Microsoft Enterprise SSO plug-in. Apps and browsers require this certificate to access resources protected by Conditional Access policies. Platform SSO is configured using the Intune settings catalog and should ideally be assigned at device enrollment, but can also be applied to existing devices. Deployment Steps Device Enrollment in Intune: Organization-owned devices use Apple Business Manager or Apple Configurator; personally-owned devices enroll via Company Portal. Prerequisites: macOS 13+, Intune Company Portal app v5.2404.0+, supported browsers (Edge, Chrome with SSO extension, Safari), Intune RBAC permissions. Create Platform SSO Policy in Intune: Enable Platform SSO, select authentication method (Secure Enclave, Password, Smart Card), assign to user groups. Define Policies in Platform SSO Settings: Assign to users or groups with user affinity; avoid assigning to device groups to prevent Conditional Access issues. Enable MDM Push Certificate: Required for macOS enrollment in Intune. Deploy Company Portal App: Via Intune or manually from https://aka.ms/EnrollMyMac. Enroll Device and Validate Profiles: Sign in to Company Portal with Entra ID credentials and confirm device management profile. Customizing the macOS Login Experience Platform SSO allows administrators to push Login Window Text and Show Full Name settings from Intune, enabling a personalized and informative login experience for users. These settings help display the user’s full name and custom messages during sign-in, improving clarity and branding. Best Practices Assign Platform SSO policies during device enrollment for a seamless experience. Ensure password policies in Intune and Entra ID are aligned. Use Secure Enclave for most users; Smart Card for compliance scenarios. Regularly review group memberships and issuer assignments for certificate-based authentication. Document all scoped policies for compliance and troubleshooting. Conclusion Microsoft Platform SSO for macOS is a game-changer for organizations seeking secure, passwordless authentication across devices and applications. By leveraging Entra ID credentials, Touch ID, smart cards, and passkeys, IT teams can deliver a modern, seamless, and secure experience for users while maintaining compliance and reducing operational overhead. Ready to get started? Explore the official documentation and accelerate your passwordless journey today!Campfire watch: Detect shadow AI & protect internet access
As employees rely more on AI tools and web-based services to get their work done, the internet has quickly become both the most-used app in your organization and its biggest security blind spot. Take a deep dive and learn how the Microsoft Entra Suite empowers you to see and control the web activity happening across your organization—without slowing down productivity or innovation. Learn how to detect shadow AI usage, dynamically enforce access policies, and stop threats before they spread. See demos of the new features that can help you control access to GenAI tools and protect your workforce from common web attack patterns. Speakers: Vincent Manna, Mohammad Zmaili, Laura Viarengo, & Martin Coetzer This session is part of the Microsoft Entra Suite Summer Camp.Trail tip: Secure access to any app—legacy to AI, no VPN needed
Whether you're accessing on-premises resources or leveraging internal AI-powered apps, relying on legacy systems puts secure access at risk. Don’t miss this change to learn how the Microsoft Entra Suite helps modernize your security strategy by replacing traditional VPNs with adaptive, identity-centric controls. Discover how the latest capabilities in the Microsoft Entra Suite enable seamless zero trust access to internal resources, whether their legacy apps or AI apps. We’ll also showcase how enriched signals—from on-premises identities to networks —enable precise, real-time policy enforcement. You’ll also learn how to extend identity as a real-time signal in your SOC. These hybrid detections help you detect risky behavior earlier, trigger risk-based conditional access, and respond faster across security information and event management (SIEM) and extended detection and response (XDR). Speakers: Abdi Saeedabadi, Marilee Turscak, Laura Viarengo, & Janice Ricketts This session is part of the Microsoft Entra Suite Summer Camp.Cabin check-in: Ensure least privilege access
The average organization spends 110 minutes onboarding or provisioning resources for a single employee. With Microsoft Entra, you can reclaim that time—accelerating productivity from day one. When employees change roles, access needs to change with them—but too often, that process is manual, delayed, or incomplete. Explore how innovations in the Microsoft Entra Suite empower to automate access transitions with precision. See how identity-driven workflows can revoke outdated permissions and grant new ones based on dynamic role attributes—ensuring the right access is applied automatically, without re-onboarding. Speakers: Reid Schrodel, Anton Staykov, Laura Viarengo This session is part of the Microsoft Entra Suite Summer Camp.Camp kickoff: Unify access, maximize impact in the age of AI
Join us as we kick off the Summer Camp with a deep dive into the scenarios that the Microsoft Entra Suite will enable for your organization. Discover how bringing identity and network access together not only streamlines your Zero Trust architecture and reduces operational burdens but also drives measurable business outcomes. Our guest speakers, Forrester Analyst, Geoff Cairns and Senior Consultant at Forrester, Roger Nauth, will reveal exclusive findings from a commissioned Total Economic Impact™ study conducted by Forrester Consulting on behalf of Microsoft. We'll highlight how organizations are achieving significant cost savings, productivity boosts, and enhanced security by unifying access with the Microsoft Entra Suite. Speakers: Kaitlin Murphy, Forrester Analyst Geoff Cairns, Forrester Senior Consultant Roger Nauth, Laura Viarengo This session is part of the Microsoft Entra Suite Summer Camp.
Update Entra ID Device Extension Attributes via PowerShell & Create Dynamic Security Groups.
2) Overview of Extension Attributes and Updating via PowerShell What Are Extension Attributes? Extension attributes (1–15) are predefined string fields available on Entra ID device objects. They are exposed to Microsoft Graph as the extensionAttributes property. These attributes can store custom values like department, environment tags (e.g., Prod, Dev), or ownership details. Why Use Them? Dynamic Group Membership: Use extension attributes in membership rules for security or Microsoft 365 groups. Policy Targeting: Apply Defender for Endpoint (MDE) policies, Conditional Access or Intune policies to devices based on custom tags. For details on configuration of the policies refer below documentation links. https://learn.microsoft.com/en-us/defender-endpoint/manage-security-policies https://learn.microsoft.com/en-us/intune/intune-service/ https://learn.microsoft.com/en-us/entra/identity/conditional-access/ Updating Extension Attributes via PowerShell and Graph API Use Microsoft Graph PowerShell to authenticate and update device properties. Required permission: “Device.ReadWrite.All”. 3) Using PowerShell to Update Extension Attributes create app registration in Entra ID with permissions Device.ReadWriteall and Grant admin Consent. Register an app How to register an app in Microsoft Entra ID - Microsoft identity platform | Microsoft Learn Graph API permissions Reference. For updating Entra ID device properties you need “Device.ReadWrite.all” permission and Intune administrator role to run the script. Microsoft Graph permissions reference - Microsoft Graph | Microsoft Learn Below is the script Important things to note and update the script with your custom values. a) update the path of the excel file in the script. column header is 'DeviceName' Note: You may want to use CSV instead of excel file if Excel is not available on the admin workstation running this process. b) update the credential details - tenantId,clientId & clientSecret in the script. Client id and client secret are created as a part of app registration. c) update the Externsionattribute and value in the script. This is the value of the extension attribute you want to use in dynamic membership rule creation. ___________________________________________________________________________ #Acquire token $tenantId = "xxxxxxxxxxxxxxxxxxxxx" $clientId = "xxxxxxxxxxxxxxxx" $clientSecret = "xxxxxxxxxxxxxxxxxxxx" $excelFilePath = "C:\Temp\devices.xlsx" # Update with actual path $tokenResponse = Invoke-RestMethod -Uri "https://login.microsoftonline.com/ $tenantId/oauth2/v2.0/token" -Method POST -Body $tokenBody $accessToken = $tokenResponse.access_token # Import Excel module and read device names Import-Module ImportExcel $deviceList = Import-Excel -Path $excelFilePath foreach ($device in $deviceList) { $deviceName = $device.DeviceName # Assumes column header is 'DeviceName' Get device ID by name $headers = @{ "Authorization" = "Bearer $accessToken"} $deviceLookupUri = "https://graph.microsoft.com/beta/devices?`$filter=displayName eq '$deviceName'" try { $deviceResponse = Invoke-RestMethod -Uri $deviceLookupUri -Headers $headers -Method GET } catch { Write-Host "Error querying device: $deviceName - $_" continue } if ($null -eq $deviceResponse.value -or $deviceResponse.value.Count -eq 0) { Write-Host "Device not found: $deviceName" continue } $deviceId = $deviceResponse.value[0].id # Prepare PATCH request $uri = "https://graph.microsoft.com/beta/devices/$deviceId" $headers["Content-Type"] = "application/json" $body = @{ extensionAttributes = @{ extensionAttribute6 = "MDE" } } | ConvertTo-Json -Depth 3 try { $response = Invoke-RestMethod -Uri $uri -Method Patch -Headers $headers -Body $body Write-Host "Updated device: $deviceName"} catch { Write-Host "Failed to update device: $deviceName - $_" } } Write-Host "Script execution completed." ________________________________________________________________________________________________________________________ Here’s a simple summary of what the script does: Gets an access token from Microsoft Entra ID using the app’s tenant ID, client ID, and client secret (OAuth 2.0 client credentials flow). Reads an Excel file (update the path in $excelFilePath, and ensure the column header is DeviceName) to get a list of device names. Loops through each device name from the Excel file: Calls Microsoft Graph API to find the device ID by its display name. If the device is found, sends a PATCH request to Microsoft Graph to update extensionAttribute6 with the value "MDE". Logs the result for each device (success or failure) and prints messages to the console. 4) Using Extension Attributes in Dynamic Device Groups Once extension attributes are set, you can create a dynamic security group in Entra ID: Go to Microsoft Entra admin center → Groups → New group. Select Security as the group type and choose Dynamic Device membership. Add a membership rule, for example: (device.extensionAttributes.extensionAttribute6 -eq "MDE") 4. Save the group. Devices with extensionAttribute6 = MDE will automatically join. 5) Summary Extension attributes in Entra ID allow custom tagging of devices for automation and policy targeting. You can update these attributes using Microsoft Graph PowerShell. These attributes can be used in dynamic device group rules, enabling granular MDE policies, Conditional Access and Intune deployments. Disclaimer This script is provided "as-is" without any warranties or guarantees. It is intended for educational and informational purposes only. Microsoft and the author assume no responsibility for any issues that may arise from the use or misuse of this script. Before deploying in a production environment, thoroughly test the script in a controlled setting and review it for compliance with your organization's security and operational policies.Protect account recovery and help desks using Face Check with Microsoft Entra Verified ID
A single impersonation attack targeting account recovery or the help desk can cost companies millions in damages. Is your organization prepared to defend itself against deepfakes and advanced impersonation? Join us to learn how to set up and deploy high-assurance, government-ID based identity verification in your account recovery and help desk processes to make sure that only the right people can perform these crucial tasks. This session is part of the Microsoft Entra Verified ID webinar series.
