23H2 Passkeys: default to security key instead of mobile devices
Microsoft invested time & money to introduce Passkeys in Windows 11 23H2, as it should. Unfortunately, it defaults to a mobile device (iPhone, iPad or Android device) everytime you try to log on. This is very annoying for everybody that is using a Security Key (FIDO2). Before we just needed to enter our PIN but now we need multiple clicks to log on. I'm not aware of a solution to manage these options (manually or through Intune). Is anyone aware of a solution? I'm quite amazed Microsoft didn't think of this.Block access with Conditional Access for Unmanaged Devices
Today, we will discuss nothing new, but it’s still a topic that remains as relevant and important as ever. If you decide to block users working from unmanaged devices, you can securely mitigate various security risks, such as data leaks and successful phishing attacks. For example, we see the rise of Man-in-the-Middle (MitM) phishing attacks, which can easily steal your credentials and access tokens and use these to sign in to your account while completely bypassing multi-factor authentication. Conditional Access can prevent these attacks without relying on phishing-resistant authentication methods such as Hello for Business, FIDO2 hardware keys, or soon Microsoft Authenticator with Passkeys. In this blog, I’ll share seven recommendations to prepare you for a smooth implementation, look at the user experience, and show you how to block access with Conditional Access for Unmanaged devices. https://myronhelgering.com/block-access-with-conditional-access-for-unmanaged-devices/Hybrid Join Lifecycle Model
Microsoft Entra hybrid join is still a common reality in enterprise environments. For many organizations, it remains necessary because legacy applications still rely on Active Directory machine authentication, Group Policy is still in use, and on-premises operational dependencies have not fully been retired. At the same time, the long-term direction for endpoint identity is increasingly cloud-native. That creates an important architectural question: Should hybrid join be treated as a permanent device state, or as a lifecycle stage in a broader modernization journey? In practice, hybrid join is often discussed as a binary condition: the device is either hybrid joined or it is not. But from an operational perspective, that view is too limited. In real enterprise environments, hybrid join behaves much more like a lifecycle. A device moves through provisioning, registration, trust establishment, management attachment, steady-state operation, recovery, retirement, and eventually transition. That distinction matters because most hybrid join issues do not fail loudly. They usually appear as stale objects, pending registrations, broken trust, inconsistent management ownership, and environments that remain temporarily hybrid far longer than intended. Why a lifecycle model is useful Treating hybrid join as a lifecycle helps explain why so many organizations struggle with it even when the initial implementation appears technically correct. The challenge is usually not the first successful join. The challenge is everything that happens around it: Provisioning quality Trust validation Management ownership Drift detection Stale object cleanup Exit criteria for transition to Entra join Without that lifecycle view, hybrid join often becomes a static design decision with no clear operational model behind it. The eight phases 1. Provisioning The lifecycle starts when the device is built, imaged, or provisioned. This stage is more important than it looks. If the device is provisioned from a contaminated image, or if cloning and snapshot practices are not handled carefully, later identity issues are often inherited rather than newly created. Provisioning should be treated as an identity-controlled event, not just an OS deployment task. 2. Registration The device becomes known to Microsoft Entra. This is where many environments confuse visibility with readiness. A device object may exist in the cloud, but that does not automatically mean the hybrid identity state is healthy or operationally usable. 3. Trust Establishment This is the point where hybrid join becomes real. A device should not be considered fully onboarded until both sides of trust are present and healthy. In operational terms, this means the device is not only registered, but also capable of supporting the expected sign-in and identity flows. 4. Management Attachment Once trust exists, governance becomes the next question. Many organizations still balance Group Policy, Configuration Manager, Intune, and legacy application dependencies at the same time. That is exactly why hybrid join often persists. But if management ownership is not clearly defined, organizations end up with overlapping policy planes, inconsistent control, and unclear accountability. 5. Operational Steady State Hybrid join does not stop at successful registration. The device must remain healthy over time, and that means monitoring trust health, registration state, token health, line-of-sight to required infrastructure, and management consistency. A device that was healthy once is not necessarily healthy now. 6. Recovery Every real environment eventually encounters drift. Pending states, broken trust, orphaned records, reimaged devices, and inconsistent registration scenarios should not be treated as unusual edge cases. They should be expected and handled with formal recovery playbooks. Recovery is not an exception to the lifecycle. It is part of the lifecycle. 7. Retirement Retirement is one of the weakest areas in many hybrid environments. Devices are replaced or decommissioned, but their identity records often remain behind. That leads to stale objects, inventory noise, and administrative confusion. A proper lifecycle model should include a controlled retirement sequence rather than ad hoc cleanup. 8. Transition This is the most important strategic phase. The key question is no longer whether a device can remain hybrid joined, but whether there is still a justified reason to keep it there. Hybrid join may still be necessary in many environments today, but in many cases it should be treated as transitional architecture rather than the target end state. Practical takeaway Looking at hybrid join as a lifecycle creates a more useful framework for architecture decisions, operational ownership, troubleshooting, directory hygiene, governance, and transition planning toward Microsoft Entra join. That is the real value of this model. It does not replace technical implementation guidance, but it helps organizations think more clearly about why hybrid join exists, how it should be operated, and when it should eventually be retired. Final thought Hybrid join is still relevant in many enterprise environments, but it should not automatically be treated as a default destination. In many cases, it works best when it is managed as a lifecycle-driven operating model with defined phases, controls, and exit criteria. That makes it easier to stabilize operations today, while also creating a clearer path toward a more cloud-native endpoint identity model tomorrow. Full article: https://www.modernendpoint.tech/hybrid-join-lifecycle-modelJoin Merill Fernando and other guests for our Identity and Network Practitioner Webinar Series!
This October, we’re hosting a three-part webinar series led by expert Merill Fernando for Identity and Network Access practitioners. Join us as we journey from high-level strategy to hands-on implementation, unifying identity and network access every step of the way. Each session builds on the last, helping you move from understanding why a unified approach matters to what are the foundations to get started, and finally to how to configure in practice. The goal is to equip you with actionable skills, expert insights, and resources to secure your organization in a unified, Zero Trust way. Register below: Identity and Network Security Practitioner Webinar Series | Microsoft Community HubMicrosoft Entra Internet Access for iOS in Public Preview!
With the latest update to Microsoft Defender for Endpoint on iOS, Organisations licensed for Microsoft Entra Suite or Microsoft Entra Internet Access will have access to Microsoft's Secure Web Gateway (SWG) and traffic forwarding for HTTP/HTTPS traffic, with support for Web-Content Filtering. This has been a huge win for iOS Mobile Security. Previously, Defender for Endpoint on iOS has supported Phishing Protection, M365 Traffic, and Entra Private Access Traffic. Combined with Global Secure Access Threat Intelligence, which consumes indicators from Microsoft Intelligent Security Graph (ISG), Organisations can implement granular internet access controls on iOS devices with integrated, context aware protection against malicious threats. Excited to hear what you think! Release notes are available hereDouble entries in userCertificate avoids Hybrid Join
Hey guys, I have an interesting situation at a customer. He utilizes a third party MFA provider while being on a federation. That means new computers never will have a registered state. For users it is mandatory that theirs clients have fulfilled the Hybrid Join to use M365 apps, what can be a real pain. So the Automatic-Device-Join task has to create the userCertificate on the OnPremises computer object, before it can be synchronized to Entra. Here comes the issue. In some cases we see that some computers will create two userCertificate entries. This situation will lead to an inconstistent Hybrid Join. I already tried to remove one of the certificates, but for me it is impossible to recognize which is the right one. Only solution for me was to remove both entries under userCertificate and let the Automatic-Device-Join task create a new one. Afterwards the Hybrid Join will work. I want to understand, which process or scenario might create the double userCertificate entries?Questions about moving Windows endpoint from locally joined domain to Azure AD
Just a couple questions, when moving a current AD domain joined endpoint (i.e. Windows 10/11 Pro) to Azure AD. 1. Does the user's desktop look/feel change upon their next Azure AD-centric login, versus their previous domain joined profile? 2. If there were previously changes pushed out to the endpoints via local AD Domain GPOs, do those changes still remain on the endpoint machine, even after the cutover to Azure AD? 3. Is there a way to have an Azure AD authenticating machine, while still allowing the machine to access local network SMB shares, if the Azure AD and Local AD domain are in hybrid mode?My favorite Conditional Access policies to implement (part two)
Today, I released part two of my blog post about my favorite conditional access policies to implement. Just like the previous post, we won't dive to deeply into each policy, but it will provide enough guidance to easily implement the policies yourself. Have a great day everyone! And give my post a read if you are interested 👍 https://myronhelgering.com/my-favorite-conditional-access-policies-to-implement-part-two
New Blog | Step-by-Step Guide to Identify Inactive Users using Entra ID Governance Access Reviews
Within an organization, inactive user accounts can persist for various reasons, including former employees, service providers, and service accounts associated with products or services. These accounts may remain inactive temporarily or for extended periods. If an account remains inactive for 90 days or more, it is more likely to remain inactive. It’s crucial to periodically review these inactive accounts and eliminate any that are unnecessary. Microsoft Entra ID Governance Access Reviews now offers the capability to detect inactive accounts effectively. Using the Entra ID Governance Access Review feature, it’s possible to identify accounts that have not been actively used to sign into Entra ID, either interactively or non-interactively, for up to 720 days. Accounts that are left inactive are susceptible to being targeted by cybercriminals for several reasons: Inactive accounts may still use well-known passwords or credentials that have been compromised. Inactive accounts are less likely to have multifactor authentication (MFA) enabled. Due to their inactivity, these accounts may go unnoticed by advanced security controls in place. Read the full blog here: Step-by-Step Guide to Identify Inactive Users by using Microsoft Entra ID Governance Access Reviews - Microsoft Community HubDeleted computer object in local AD still in Azure AD
Hi, I'm dealing with a client who reported the following "issue". They have configured Azure AD Connect and device sync, everything seems to work. They deleted some computer objects from AD (dsa console) without disjoining them beforehand. Azure AD Connect continues to perfom synchronizations, but the computers still appear in Azure AD with Join Type <empty> (no longer Hybrid Azure AD Joined). I'm wondering if this is normal and those computersmust be manually deleted from Azure AD, or Azure AD should automatically delete the computers objects once the related AD object is deleted. Kind Regards, David
