Microsoft Feedback Portal account is not working
I changed my Microsoft password a year ago, and it updated everywhere other than the Feedback Portal. As a result, I get an error when I try to login, or do anything on the page. Microsoft account support's suggestion was to login to the Feedback Portal which is insane given I'm having issues accessing it. How can I get this issue resolved? I've got three separate support tickets now and they keep asking me to wait 24 hours to get the issue resolved. Can someone from the Feedback Portal team please contact me to resolve this?" This is what Microsoft Support have said: "understand your frustration, and yes—this is an account‑related issue because the Feedback Portal is still tied to your old alias, which causes login conflicts and forces you out. Your Microsoft account itself signs in correctly, but the Feedback Portal is pulling outdated identity data that you cannot update on your own. Since you cannot access the Portal to submit feedback, directing you back there is not a workable solution. What you need is for Support to escalate this to the internal Identity/Feedback Platform engineering team so they can manually correct the outdated alias mapping on the backend. In this situation, the Feedback Portal and Tech Community teams are the ones who manage and maintain that specific platform. Because the issue appears on the Feedback Portal side—even though your Microsoft account is working normally—only their dedicated team can make the necessary corrections on their end. That’s why we are guiding you to connect with them through the links provided: https://techcommunity.microsoft.com/ or https://feedbackportal.microsoft.com/feedback. They will be able to review the portal‑specific account data and assist you further. I understand why this is frustrating. Since you’re unable to stay signed in to the Feedback Portal, I completely see why posting there isn’t possible for you. However, I do need to be transparent: I’m not able to escalate this issue directly to the Feedback Portal team, as they don’t provide internal escalation channels for us and only accept requests through their own platform. "
My Azure login is stuck at MFA and cannot proceed
In August, I was still able to log in to Azure, and by logging in through GitHub I could bypass 2FA. But now, no matter how I try, logging in via GitHub always requires 2FA. I can’t access my Azure account anymore—nothing works. The system prompts me to use Microsoft Authenticator to confirm a two-digit code in real time. My Microsoft Authenticator on my iPhone is logged into the same Microsoft account, but I’m not receiving any verification requests for Azure login. No matter how much I refresh, nothing shows up. I’ve already updated the Microsoft Authenticator app to the latest version from the App Store. However, my personal Microsoft account works fine and can log in without any issues.
Microsoft Authenticator Passkeys for Entra ID on unmanaged devices
Hello, has anyone successfully registered passkeys on an unmanaged phone in an organisation with device compliance policies? Use case is to provide a phishing-resistant MFA option via Authenticator app for logging into apps on their desktop. Users already have authenticator app on their phone and do number matching MFA. https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-register-passkey-authenticator?tabs=iOS When I select "Create a passkey" - I need to log into my account. However I'm blocked from successful authentication because I have conditional access policies to require compliant devices. As my mobile phone is not enrolled into Intune, I never get to the step where the passkey is created and registered. Based on the constraints - it seems like passkeys cannot be used for unmanaged/BYOD devices for organisations that have device compliance policies. It can only be used for users who have enrolled their mobile phone. Looking to see if anyone has tips or different experience using passkeys on unmanaged mobile phones to log into Entra?Upcoming changes to iOS/iPadOS Company Portal app deployment for Setup Assistant with modern auth
Learn more about plans to remove automatic deployment of the iOS/iPadOS Company Portal app as a required app for Automated Device Enrollment (ADE) Setup Assistant with modern authentication enrollment profiles.Windows Hello for Business 0x80090010 NTE_PERM
Hi all, I'm encountering an issue with Windows Hello for Business on the latest version of Windows (July 2025 update). The setup process fails during initialisation, and no biometric or PIN options are being provisioned for the user. Environment: Windows version: 11 24H2 Enterprise (latest update) Deployment mode: Hybrid Cloud Trust Hybrid joined devices Symptoms: Users are prompted to set up WHfB but the process fails at the last step with error 0x80090010 Users who already have WHfB authentication methods created can successfully login Event ID 311 & 303 in the User Device Registration logs Screenshots: Troubleshooting so far: Unjoined and rejoined to Entra ID Granted modify permissions on folder in which NGC container would be created Rolled back to June 2025 update (this worked) So it seems like this is caused or related to the latest Windows Update, which is rather unfortunate for us as we are just beginning to rollout WHfB for our organisation. I'm posting here to raise awareness of the issue, if there is a more appropriate place to post then please suggest.Support tip: Aligning network policy with Microsoft Intune and Zero Trust
By: Jon Callahan – Sr Product Manager | Microsoft Intune Cloud services don’t just rely on the network. They redefine it. As organizations adopt Microsoft Intune and advance their Zero Trust strategies, many discover that traditional, perimeter-based architectures no longer align with modern security expectations or the connectivity needs of a distributed workforce. Zero Trust is built on the principle of "never trust, always verify,” where access decisions are enforced through identity, device health, and compliance signals. Microsoft Intune strengthens this model by extending security and management through the cloud. By removing dependencies on on-premises infrastructure, it strengthens network resilience and Zero Trust enforcement with policy-driven device management and secure connectivity to Microsoft endpoints. This is where friction occurs. Traditional enterprise networks were built around a castle-and-moat model of perimeter defense: build high walls around the perimeter and trust everything inside, rather than identity-based access. Centralized egress points, VPNs, proxy servers, and deep packet or TLS inspection worked well when apps, data, and users stayed inside the moat. Today, work and data are everywhere. Legacy network designs often force traffic into hairpinned routes (indirect paths through central gateways) that add latency, reduce performance, and increase management overhead for Intune, Microsoft 365, and other SaaS apps. The challenge deepens when network teams try to maintain allow lists for cloud services using static IP addresses. Microsoft’s endpoint IPs can change frequently, especially with CDN-backed services like Intune and Microsoft 365, to strengthen security, improve resilience, and scale globally. This is why Microsoft recommends domain-based egress policies, frequent updates based on the published endpoint lists, and bypassing SSL inspection for Microsoft-bound traffic that doesn’t support inspection. Enabling cloud services The shift to hybrid work environments shows the limits of perimeter-based networks. Users expect fast and reliable access to their apps and data whether at home, in the office, or on the go. To support this shift, organizations need to modernize their network architecture and policies. Local internet egress and optimized paths to trusted services like Intune are essential. Policies built on Zero Trust and cloud-native principles help ensure performance and security. In contrast, controls such as VPN-only access, TLS inspection, or centralized proxies often slow users down and block required endpoints. When networks get in the way, the impact is noticed: Device check-ins and compliance evaluations fail, leaving devices marked as non-compliant Enrollments stall or time out Apps download slowly, fail to update, or never install When these failures occur, users often blame Intune or their IT admins, even when the real issue is network policies. In a Zero Trust model, network policy works alongside identity and device-based signals to enforce access decisions. Network policy should enable cloud services, not obstruct them. Adopting cloud-native connectivity and Zero Trust enforcement protects users, devices, and data while improving reliability and user experience. This approach aligns with Microsoft’s Secure Future Initiative (SFI) and the principle of “Secure by Design,” which extend Zero Trust principles into the foundation of how services are built and operated. As part of this effort, Intune service endpoints are moving to Azure Front Door to enhance security, reliability, and performance while simplifying firewall management across Microsoft services. For details on required IP addresses and endpoints, see Support tip: Upcoming Microsoft Intune network changes. Outbound traffic management Aligning network policies with Zero Trust and cloud-native architecture can require trade-offs. Outbound traffic management is critical for Intune’s performance, but organizations differ in their compliance needs and tolerance for complexity. Below are three common models we see with our customers. Endpoint enforced access This model eliminates perimeter bottlenecks by moving enforcement closer to the user, device, and apps, which is the core of Zero Trust. Enforcement happens at the endpoint through identity, compliance, and device health signals, while the network provides fast, direct internet access with minimal restrictive filtering. Best for: Organizations ready to adopt a Zero Trust network architecture built on Intune and identity-driven signals, or those with minimal outbound filtering requirements. How to implement: Policy-based enforcement and compliance: Intune enforces and validates device health and measures device compliance and app protection policies for Microsoft Entra Conditional Access Identity-driven enforcement: Microsoft Entra Conditional Access evaluates signals such as user identity, device compliance, and risk level before granting access to cloud resources Threat protection: Microsoft Defender for Endpoint monitors device risk and blocks compromised endpoints from accessing cloud resources; enforce the built-in firewall on Windows and macOS devices Bypass traffic inspection: Don’t decrypt or inspect Intune and related Microsoft traffic using technologies like proxies, TLS inspection, deep packet inspection, or data loss prevention systems Use split-tunnel VPN and local internet egress: Route Intune and Microsoft 365 traffic locally to avoid unnecessary hairpinning Benefits: Establishes Zero Trust controls with identity, device, and threat-based enforcement Local internet egress and optimized paths to Intune and Microsoft 365 avoid latency and centralized paths No allow list or complex firewall rules to manage Avoids VPN, proxies, and TLS inspections and reduces the risk of interfering with user experience and device management failures This model requires strong endpoint management and identity controls to ensure Zero Trust enforcement. Domain enforced filtering When endpoint-only enforcement doesn’t meet your organization's requirements, Fully Qualified Domain Name (FQDN) filtering offers a middle ground by adding network controls while staying adaptable to dynamic cloud services. This approach should be paired with endpoint enforcement to maintain a Zero Trust architecture. Best for: Organizations that need outbound restrictions for compliance, while maintaining reliability and flexibility in cloud services. How to implement: Use domain-based rules: Filter traffic by FQDN rules that rely on DNS to adapt to changing IP addresses and CDN-backed services. Leverage automation: Leverage the consolidated endpoint list, Azure Firewall service tags, or vendor tools to keep rules up to date. Bypass traffic inspection for trusted services: Avoid decrypting or inspecting Intune traffic, which can break certificate pinning and cause service failures. Resolve locally: Use local DNS and Internet egress so devices connect to the closest Microsoft endpoint. Benefits: Builds on endpoint enforced Zero Trust controls Easier maintenance than IP-based filtering Automatically adapts to Microsoft's dynamic, cloud-hosted services Reduces service disruptions when automated Aligns with most regulatory and compliance frameworks This model requires more robust network automation and may introduce additional processing overhead compared to endpoint-enforced access. Domain and IP enforced filtering This model combines FQDN-based rules with IP filtering for the strictest assurance. It provides maximum control but introduces the most overhead. Like domain enforced filtering, this too should be combined with endpoint enforcement to maintain a Zero Trust posture. Best for: Organizations in highly regulated industries that require dual enforcement with domains and IPs to meet strict audit and assurance needs. How to implement for Intune: Combine domain with IP rules: Use FQDN alongside IP address ranges to filter traffic. Automate aggressively: Leverage the consolidated endpoint list, Azure Firewall service tags, or vendor tools to keep rules up to date. Bypass traffic inspection for trusted services: Exclude certificate-pinned services from TLS inspection to avoid breaking Intune functionality. Optimize performance: Architect your network to use local DNS and internet egress so devices connect to the closest Microsoft endpoint. Benefits: Builds on Zero Trust with the strictest network controls Provides dual verification for outbound traffic Helps satisfy strict regulatory and compliance requirements This model introduces the highest administrative overhead and complexity to maintain. It’s also the most likely to cause performance issues and service disruptions if not properly automated. However, for organizations with strict regulatory requirements, these trade-offs may be necessary to meet compliance obligations. Extending with cloud-first controls While traditional network models address outbound traffic at the infrastructure layer, a Zero Trust approach uses cloud-native security tools that eliminate many of these challenges. Issues like hairpinning, brittle IP allow lists, TLS inspection conflicts, and complex firewall rules stem from applying perimeter-era tools to cloud-based services. Cloud-first network and security tools reduce friction and strengthen Zero Trust. Cloud-delivered secure web gateway (SWG): Provides secure access to internet and SaaS apps while protecting against internet threats, building on the capabilities of traditional proxies (Microsoft Entra Internet Access) Zero Trust Network Access (ZTNA): Connects users securely from any device and any network without relying on VPNs or central tunneling (Microsoft Entra Private Access) Data loss prevention (DLP): Protects sensitive information across endpoints, Microsoft 365 apps, SaaS services, browsers, and on-premises file shares, with classification and policy enforcement (Microsoft Purview DLP) Cloud access security broker (CASB): Provides SaaS discovery, session control, and real-time policy enforcement (Microsoft Defender for Cloud Apps) Managing outbound traffic for cloud services is about more than connectivity. It’s about aligning network policies so they enable cloud services and embrace Zero Trust principles like identity, device health, and compliance signals over legacy perimeter defenses. Microsoft Intune supports through policy-driven device management and security that reinforce Zero Trust and cloud-native adoption. The result is an architecture that secures your environment and delivers the reliability and user experience needed for today’s hybrid work. Resources Intune network endpoints US government network endpoints for Intune China endpoints for Intune Support tip: Upcoming Microsoft Intune network changes Microsoft 365 network connectivity overview Azure Front Door Azure service tags Microsoft Secure Future Initiative (SFI) Microsoft Zero Trust As always, if you have any questions let us know in the comments or reach out to us on X @IntuneSuppTeam! Post updates: 11/06/25: Updated URLs for Automation category (see Domain-Enforced Filtering section).
failed set-up of a passkey for a personal MS account
After scanning the QR code (on the PC screen) in the Authenticator app on the Iphone, the error message “Error adding the passkey - Microsoft Authenticator does not support this passkey” (translated from German) appears. What does this mean ? How to prevent? Any help is appreciated.TAP Question
Hi All I hope you are well. Anyway, I'm looking for some clarification over Temporary Access Passes (TAP) as our testing seems to reveal some different results from those listed in the MS documentation. Here's the scenario's. My understanding: Require MFA policy deployed via Conditional Access New user F3 user starts Issue TAP to user where they can then setup MFA themselves via My Security Info etc Testing results: Require MFA policy deployed via Conditional Access New user F3 user starts User can setup MFA themselves via MS Auth app on a mobile device or via My Security Info in a browser MS TAP Info page: "The most common use for a TAP is for a user to register authentication details during the first sign-in or device setup, without the need to complete extra security prompts." Ref: Configure a Temporary Access Pass in Microsoft Entra ID to register passwordless authentication methods - Microsoft Entra ID | Microsoft Learn Have I missed understood something here and if a new user can indeed still setup MFA is there any real need for a TAP for first time user? Info appreciated. SK
NgcSet stays NO despite working WHFB setup - RPC 0x800706ba error
Hi everyone, I need help with a Windows Hello for Business certificate trust deployment that's almost working but stuck on the final step. **What's Working:** - Manual certificate enrollment works perfectly: `certreq -enroll -user -config "MyCA.domain.local\MyCA-CA" "MyWHFBTemplate"` - TPM 2.0 is ready, enabled, and functional - All Group Policies applied correctly (computer and user) - CA server healthy, templates published **What's NOT Working:** - `dsregcmd /status` shows `NgcSet : NO` (should be YES) - `NgcSvc` (Microsoft Passport) service is stopped on client - Getting error: "RPC server is unavailable (0x800706ba)" during automatic certificate enrollment - PIN setup fails because NGC containers won't create **The Strange Part:** Manual certificate enrollment works perfectly, but automatic enrollment fails with RPC errors. Both should use the same communication path to the CA. **Environment:** - On-premises certificate trust deployment (no Azure AD) - Domain-joined Windows 11 clients - Windows Server 2019/2022 infrastructure **Questions:** 1. Should NgcSvc start automatically when WHFB policies are applied? 2. Why would manual cert enrollment work but automatic fail with RPC errors? 3. Is there a difference in how system context vs user context accesses the CA? Has anyone seen this specific combination before? Any ideas what could cause this behavior? Thanks for any help!
