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

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.

• 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
• the diagrams in posts, which are written as a few lines of JSON and turned into HTML and SVG at build time

The 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

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.

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.

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.

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.

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

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.

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.

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.

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 shows what each permission allows and suggests narrower alternatives.

If you find a malicious grant

1. Remove the app's permissions and disable sign-in for the Enterprise App.
2. Revoke the affected users' sessions.
3. Check the audit log for when consent was granted and by whom.
4. Check what the app accessed, using the mailbox and SharePoint audit logs.

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.

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

1. Create an app registration, single tenant.
2. Under Certificates & secrets, upload the .cer file.
3. Under API permissions, add the Application permissions the script needs, such as User.Read.All, and grant admin consent. Keep it to the minimum.
4. Add at least two owners.

3. Connect in the script

Connect-MgGraph -ClientId "<app-id>" -TenantId "<tenant-id>" `
  -CertificateThumbprint "<thumbprint>" -NoWelcome

Get-MgUser -All -Property DisplayName,UserPrincipalName,AccountEnabled |
  Export-Csv C:\Reports\users.csv -NoTypeInformation

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

1. About a month before expiry, create a new certificate on the server, as before.
2. Upload the new .cer to the app registration. Both certificates now work.
3. Update the thumbprint in the script, or the scheduled task's parameter, and test a run.
4. 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.

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

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.

What to do now

1. 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.
2. 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.
3. 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.
4. Use the registration campaign. It now supports passkeys, so users are prompted at sign-in rather than chased by email.
5. 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.

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

1. 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.
2. 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.
3. Weeks 3 to 4: communicate. Tell users what a passkey is and what the prompt will look like, before they see it.
4. Weeks 4 to 8: campaign. Let the registration campaign prompt people at sign-in. Limit snoozes once most users have registered.
5. Ongoing: chase the tail. Contact the remaining SMS-only users directly, and issue Temporary Access Passes where people are stuck.

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
  }
}

Questions people ask

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.

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.

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

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.

• 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

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.

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:

1. Budget threshold at 100% of actual cost calls an action group.
2. The action group starts an Automation runbook with a managed identity.
3. 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

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.

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

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:

1. Deploy an Azure DNS Private Resolver with an inbound endpoint in the hub.
2. 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.

# 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 can control data access with vault access policies (the original model) or Azure RBAC. Microsoft recommends RBAC, and there are good reasons.

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

Switching over

1. List the existing access policies and map each to an RBAC role.
2. Create the role assignments before switching. Role assignments can take a few minutes to take effect.
3. Switch the permission model:

az keyvault update --name kv-app-prod --resource-group rg-app --enable-rbac-authorization true

4. Test every app that uses the vault. If something breaks, switching back restores the old access policies.

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

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.

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.

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

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.

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.

4. Rotate on demand

Use the Rotate local admin password remote action after a password has been shared during a support call.

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.

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.

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

1. Confirm the issue: the user will see Authenticator refuse to add or use their work account.
2. Issue a Temporary Access Pass so they can sign in and register a different method.
3. Offer an alternative: a supported phone, a FIDO2 security key, or Windows Hello for Business on their work PC.
4. 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.

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.

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.

A sensible policy set

Registering a device

1. On the personal PC, open Settings → Accounts → Access work or school and select Connect.
2. Sign in with the work account and complete MFA.
3. 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

Putting these answers in your onboarding guide removes most of the hesitation users have about connecting a personal PC.

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.

Get ready before your notification lands

1. Inventory your current setup. List the custom sync rules, filtering, writeback options and other features you depend on.
2. 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.
3. Read the migration guide and try Cloud Sync in a test environment or on a pilot OU.
4. 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.

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.

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

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.

Where to start

An Endpoint Privilege Management pilot

1. List the reasons users currently need local admin, from your service desk tickets.
2. Create elevation rules for the most common ones, such as a specific installer or tool.
3. Pilot with a team that has admin rights today, then remove their local admin membership.
4. Review the elevation reports weekly and add rules where requests repeat.

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.

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

1. In the Entra admin center, open Backup and recovery.
2. Under Backups, pick a snapshot from before the change.
3. Create a Difference report. It shows exactly which attributes and links differ from the current state.
4. Review it carefully, then use Recover objects to restore everything, specific object types or specific object IDs.
5. Track progress under Recovery history.

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.

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.

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

1. Start with high-risk apps: finance, HR, anything holding client data, and any app with its own admin accounts.
2. Review the orphaned accounts with the app owner. Some will be service or break-glass accounts that are meant to be there; document those.
3. Disable the rest in the app, and fix the process that created them.
4. Bring legitimate users under Entra assignment so future joiners and leavers are handled automatically.

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

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.

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

1. Find devices with no sign-in activity for a long period, such as 90 days or more, using the approximateLastSignInDateTime property.
2. Disable them first and wait. If nobody complains, move on.
3. Check Intune and your other tools so you're not deleting a device that's still managed.
4. 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

Before you delete anything

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 }

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.

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

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.

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.

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.

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.

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.

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.

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 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.

Wrapping the app

Intune deploys Win32 apps as .intunewin files created with the Microsoft Win32 Content Prep Tool:

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.

Return codes

Intune needs to know what each installer exit code means. The defaults cover the common ones:

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

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.

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

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?

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.

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

Testing a change

1. Create the policy and assign it to a test copy of the app, or the real app with a pilot group.
2. Sign in, then decode the access token with the JWT decoder and compare iat and exp to confirm the new lifetime.
3. Use the app past the lifetime to make sure it renews tokens quietly instead of failing.
4. Roll out to everyone and record why the policy exists.

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.

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

1. 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.
2. 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.
3. Test in report-only mode, then switch it on.
4. 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.
5. 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.

• 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

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.

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.

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?"

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.

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

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.

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

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.

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

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.

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.

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.

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 reports both.

Two passkey features reached general availability together, and they're designed to be used as a pair.

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

This gets most users onto phishing-resistant sign-in with very little friction, while keeping a tighter grip on the accounts attackers want most.

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.

Rolling it out

1. Check what your existing passkey settings migrated into. Tenants that already had passkeys configured get a default profile with those settings.
2. Create the admin profile first and test it with two or three admins, including registration on a new device.
3. Widen the standard profile to allow synced passkeys, then run a registration campaign.
4. Once most users have a passkey, require the phishing-resistant MFA 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