Navigating the Rollout: Best Practices for Conditional Access and Device Code Flow

The rollout of Microsoft-managed policies to block Device Code Flow in conditional access will impact remote management and login processes for Teams devices, common area phones, and Teams Rooms devices. As the default policy will be set to block device code flow, administrators need to adopt best practices to leverage conditional access effectively. This blog post outlines the key impacts of this change and provides practical recommendations for allowing device code flow to ensure seamless and secure remote management.

Starting in February, 2025 and continuing through May, Microsoft is implementing the block on device code flow (DCF) authentication to enhance security and protect tenants against potential threats. The new Microsoft-managed policy aims to secure accounts using DCF authentication by initially rolling out in report-only mode, allowing administrators to review the impact before enforcement. Administrators have at least 45 days to evaluate and configure the policies before they are automatically moved to the "On" state.

The policy changes are particularly important for Android-based shared Teams devices, such as Microsoft Teams Rooms on Android, IP Phones, and Panels. Without creating exclusion lists for these devices, administrators will lose the ability to remotely sign in and manage them after sign-out, as they will not be able to re-authenticate with DCF.

Take a moment to review the blog post covering this announcement and bookmark for future updates:

https://techcommunity.microsoft.com/blog/microsoftteamsblog/policy-changes-for-microsoft-teams-devices-using-device-code-flow-authentication/4399337

While we acknowledge the possibility of exclusions, additional conditional access rules can enable remote logins through device code flow. However, this approach must align with enhanced security protocols aimed at restricting device code flow. This includes measures like security group membership, trusted location verification or limiting device code access exclusively to administrators overseeing common areas, such as rooms and shared phone devices.

UPDATE - also take a look at Daryl's blog here for all impacting device management updates

https://darylhunter.me/blog/2025/04/upcoming-teams-devices-updates-spring-summer-2025.html

Options:

• Trusted Locations: Permit device code flow only when initiated from known IP ranges (e.g., office subnets or VPN IPs).
• Named Locations with MFA: Require MFA for named locations if allowing device code flow for users with devices outside of your main perimeter.
• User/Group Scope: Limit the exclusion policy to only specific device accounts used for Teams devices.

Additional monitoring and reporting of DCF use:

• Track usage of device code flow.
• Set up alerts for unexpected geolocations, time-of-day logins, or unusual IPs

The default policy:

Initially the Microsoft managed policy will be implemented in report-only mode.

At the time of this post, the policy was created manually, the Microsoft managed policy is not deployed to this tenant.

The policy may look something like this:

Note the policy is applied to all users and the grant control is set to block.

In report-only mode, we can review sign-in logs, and select conditional access report-only to confirm this policy would block the DCF authentication flow. 

Authentication Redirect is used for Teams Room Device QR Code Join - so this may also be blocked by default.

If this policy is moved from report-only to enabled:

The device screen will still present a remote login prompt:

When navigating to authentication broker remote login, the remote authentication attempt will fail (an account can still log in directly from the device - but this may be difficult for admin's remotely managing devices, or local resources who would need to navigate a smaller device screen, or non-touchscreen devices) 

Remember the Microsoft managed policy default settings block DCF for all users with no excluded accounts or devices.

Modify the Policy:

Lets modify the policy to require Compliant Device and allow from trusted location(s).

Exclude the named location as trusted and exclude the named trusted location from the block DCF policy - if your organization has not leveraged named locations before the guidance can be found HERE

Navigate to the Device Code Flow policy - and exclude the named trusted location.

Additionally you can require only compliant devices. There are a few ways to accomplish this. One option is to build an additional exclusion device filter applied to the condition.

When configuring Conditional Access policies in Microsoft Entra ID (formerly Azure AD), the behavior of exclusions depends on how the conditions are set up. If you apply exclusions for both named trusted locations and devices marked as compliant, the exclusion will take place if either condition is met. This means that if a sign-in attempt comes from a named trusted location or from a device marked as compliant, the policy will exclude that attempt from the restrictions.

An alternate, more secure method is applying a grant control, requiring a compliant device.

Note - when selecting "Require device to be marked as compliant" the grant control changes from Block Access to 1 (or more) controls selected.

Requiring device compliance as a grant control is generally considered more secure because it enforces compliance checks at the point of access, ensuring that only devices meeting the organization's security standards can access resources. You may apply this grant control to all cloud applications within a specific policy, not nested within the DCF exclusion. This approach reduces the risk of unauthorized access and provides a higher level of security compared to excluding devices marked as compliant, which may leave gaps if not carefully managed.

Result:

It's important to note that while excluding trusted named locations is one way to permit Device Code Flow (DCF), alternative approaches may offer a stronger security posture. For example, instead of relying solely on location-based exclusions, consider limiting DCF access to only shared device accounts—such as Teams Rooms and common area phones by using a dedicated security group. This ensures DCF is tightly scoped to specific, low-privilege identities used solely for device provisioning and management.

Closing Thoughts:

As Microsoft continues to tighten the security posture of identity and access management through managed policies like the DCF block, it’s essential for organizations to strike the right balance between usability and protection. While trusted named locations offer a straightforward method for allowing device code flow, more robust alternatives—such as scoping access to dedicated security groups for Teams Room and shared device accounts—provide greater assurance against misuse. By leveraging Conditional Access, enforcing least privilege, and monitoring sign-in activity, organizations can maintain a strong security posture without disrupting the legitimate provisioning and management of Teams devices.

Passwordless Signin with MFA and Microsoft Authenticator

I wanted to take a moment to chat about something that's been on my mind lately: Microsoft's Secure Future Initiative (SFI). It's a pretty big deal around here, and I think it's worth diving into what it's all about and why it matters.

So, what exactly is SFI? In a nutshell, it's Microsoft's commitment to making sure our technology is as secure as possible. This isn't just a one-time thing; it's an ongoing effort to stay ahead of the ever-evolving threat landscape. The initiative is built on three core principles: Secure by design, secure by default, and secure operations.

As an architect working with customers and supporting demonstration and development environments with multiple user personas, MFA with passwordless sign-in optimize and secure my activity and environment. They ensure that all user personas, whether for testing or demonstration purposes, are protected against unauthorized access. These principles not only apply to demonstration and development environments, they expand to enterprise-wide enablement strategies, adding value by maintaining robust security standards and improve end-user interactions.

One of the coolest things about SFI is how it ties into our push for passwordless authentication combined with multi-factor authentication (MFA). If you haven't heard, passwordless authentication is a game-changer. It eliminates the need for traditional passwords, which are often the weakest link in security. Instead, we use things like biometrics or security keys, making it much harder for bad actors to get in.

Combining passwordless authentication with MFA adds an extra layer of security. Even if someone manages to get past one barrier, they've still got another to contend with. This approach not only boosts security but also makes life easier for users. No more juggling multiple passwords or dealing with the hassle of password resets - or even worse, storing passwords in less than optimal places.

While passwords can be stored in authenticator, ensuring you aren't storing passwords in documents or cloud storage files,  Passwordless sign-in takes security to the next level. By using methods like biometrics (fingerprint or facial recognition) or security keys, it eliminates the need for traditional passwords altogether. This not only reduces the risk of password-related attacks but also simplifies the user experience. With passwordless sign-in, you can access your accounts quickly and securely.

Getting Started

Enabling Passwordless authentication is different than enabling Microsoft Authenticator for Multifactor Authentication. Many tenants and users may already have MFA required (if not I highly recommend). The additional documentation and steps below walk through the additional steps to add passwordless authentication to authenticator based MFA.

https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-passwordless-phone

First we start in Entra ID under policies and authentication methods.

Note in these screen shots - application name and location are marked as Microsoft Managed - you have the option to set these to enabled as an additional control to ensure users approve the application and location they are accessing from.

User registration

Users register themselves for the passwordless authentication method of Microsoft Entra ID. For users who already registered the Microsoft Authenticator app for multifactor authentication, skip to the next section, enable phone sign-in.

Its important to note here that users may have already enabled the Authenticator App for MFA which is important to do, but doesn't complete the enablement of passwordless signin.

Guided registration with My Sign-ins

To register the Microsoft Authenticator app, follow these steps:

1. Browse to https://aka.ms/mysecurityinfo.
2. Sign in, then select Add method > Authenticator app > Add to add Microsoft Authenticator.
3. Follow the instructions to install and configure the Microsoft Authenticator app on your device.
4. Select Done to complete Microsoft Authenticator configuration.

Enable phone sign-in from your authenticator app

After users registered themselves for the Microsoft Authenticator app, they need to enable phone sign-in:

1. In Microsoft Authenticator, select the account registered.
2. Select Enable phone sign-in.
3. Follow the instructions in the app to finish registering the account for passwordless phone sign-in

In our policy we administratively still allow for password signin but now the user can define passwordless signin as the default method.

Once enabled the end users (or test users in our development environments) are no longer prompted for password or they can set password to the default method, and select alternate options in the login process (as shown below)

I hope this post was helpful in guiding through the deferent security and authentication practices. I plan to follow up with a future post discussing the use and enablement of Passkey. Passkeys are a strong, phishing-resistant authentication method that completely replace the need for a password when logging into applications and websites. They are created and stored on a user's device, such as a smartphone or computer. Using a passkey is as easy as using your face, fingerprint, or device PIN. Passkeys are designed to be highly secure and user-friendly, making them the preferred way to sign in. Stay tuned.

Manufacturing, Healthcare and Retail Voice with Teams Phone

In today's business environment, seamless communication is more important than ever, especially in sectors like manufacturing and retail, where quick, clear coordination can significantly impact operations. While DECT technology continues to evolve as a valuable communications platform, many organizations are looking for modern solutions that offer more flexibility and integration. Microsoft Teams Voice has become a comprehensive platform that provides everything you need, including dial-by-name functionality for simplified communication.

However, extension-based dialing remains crucial for certain use cases, especially in fast-paced environments where speed and simplicity are key. Whether it's contacting a production manager in manufacturing or reaching a sales team member on the retail floor, or a trauma nurse in the ICU, the ability to quickly dial an extension can save time and reduce confusion.

Enter Teams Shared Calling—a game-changing integration that not only simplifies IT management but also reduces costs by streamlining how organizations connect to PSTN services. By combining these three elements—DECT (through Teams SIP Gateway), Teams extension dialing, and a recent Microsoft product update enabling extension dialing through Shared Calling —businesses can build a communication system that meets both traditional and modern needs.

In this post,  my peers Pratik, Matt and I will help explore how to leverage all three technologies to create a streamlined communication platform, with a focus on practical use cases in manufacturing, healthcare and retail.

I need to thank our partner ecosystem for making this example implementation possible.

• Jacob Lauritsen, Pumi Powar, and Craig Barrass - Spectralink DECT and Teams Phone solutions
• Rick Garcia, Mark Vale, and Jeffery Head - Momentum Teams solutions for Operator Connect integration supporting Fax and SMS solutions in Teams
• Gary Wood, and Diana Florea, Andrew Steinke - PureIP for seamless integration of Operator Connect and hosted direct routing for global PSTN services.

Extension dialing is not a new concept in Teams calling, yet is still controversial. In Teams, and other UCaaS solutions, users and numbers are tied to identities for security and license capabilities and the concept of dial-by-name is widely encouraged. Where there is ongoing development and extension dialing may still be useful is shared device scenarios, specifically where SIP endpoints are used, and directory search isn't always available. 

Here we will review setup and options.

          
PBX to Shared Calling SIP device       Teams SIP to SIP Device

Components used in our recipe

• Teams users - enabled with Phone System and Operator Connect
• Teams features - dial plan normalization rules, shared calling policies (and PLAR/Ringdown when faster access is needed)
• Spectralink DECT solutions - IP-DECT Server 400, IP DECT Base Station, S33 and S37 DECT handset
• Shared Calling DID's from Operator Connect carrier partners
• Teams Native Phones - Poly/HP CCX500 for PLAR/ringdown

Scenarios

• Scenario - Nursing station needs to reach any nurse working in wing
• Scenario - Plant production manager needs to reach any worker in production group 2 
• Scenario - Retail manager needs to reach anyone working in cashier role

Connectivity Configuration

• Enable shared calling following this guidance - https://learn.microsoft.com/en-us/microsoftteams/shared-calling-setup
• In this scenario we will use 2 groups of users - 2 shared calling policies
• Configure 2 resource accounts with Operator Connect numbers, one for each shared calling group.
• In a practical application each group may be defined by emergency location or floor of a building.

We will also want to create a caller ID policy for the users to leverage the DID from each shared calling group (policy) - note the setting below - Replace the caller ID with Resource account.

Users and Shared Devices

• Assign licenses to users (Teams Phone System) and shared devices (Shared Device License)
• Assign policies
• Assign user phone numbers extensions using direct routing type - here is where recent feature and documentation updates come into play - https://learn.microsoft.com/en-us/microsoftteams/shared-calling-setup#step-10-configure-extension-dialing-support-for-shared-calling-enabled-users-optional
• Map extension ranges to shared calling policies (main resource account DID and emergency location)
• In this example setup shared calling user group 1
• Operator Connect DID - Assigned in shared calling policy to resource account 1
• User assigned same phone number as shared calling resource account 1 (type is direct routing)
• Extension Range - 4000 assigned to users with policy 1
• Shared calling user group 2
• Operator Connect DID - Assigned in shared calling policy
• User assigned same phone number as shared calling resource account 2 (type is direct routing)
• Extension Range - 5000 assigned to users with policy 2

Note - we use number type direct routing on the user assignment (allowing for the DID from the shared calling resource account and extension assignment).

At this point we have to set up some additional policies for dial plan and normalization rules and then we can assign all the needed policies for each user.

Extension Dialing

In this example setup - we are not using the last 4 digits of each DID since our users don't have a DID in shared calling. Increasingly sequential DID blocks are becoming harder to obtain and maintain - and often you may find yourself with overlapping (or duplicate) extension numbers based on last 4 digits of DID - so in this case we mapped extension range 4000 to shared calling group 1 and extension range 5000 to shared calling group 2.

• Create a Dial Plan and Normalization Rules

• Here we apply the shared calling resource account DID number to the translation (in the "Then do this" section), with the ext=$1
• Assign dial plan policies to users

Scalability - optional on-prem integration - the same extension dial plans can be applied in the SBC or on-prem PBX as needed. 

Outcome

• All users and shared devices can place outbound calls
• Inbound calls from PSTN can be routed to users through auto attendant and dial by name or dial by extension
• Users can quickly call each other - between devices with extension dialing or dial-by-name in the Teams client, web, mobile app or native phones.

Spectralink Tools

Spectralink provides unique features adding additional value to Teams Phone.

• Ringtone choices, loud ringing and visual alerts
• Messaging
• Admin Profiles/Speed Dial phonebook management
• Range Extension
• Personal Safety Alerts and lighting assistance

Additional Value - Shared calling users receive inbound calls through the optional auto attendant configures and assigned to the Resource Account. PLAR/Ringdown phones can be configured to automatically dial the Auto Attendant for the shared calling users - allowing gloved worker to speak the name or the extension of the shared device users or speed dials can also be used for quick access to users and devices.

Keep your eye on M365 Roadmap and Message Center - admin managed speed dial contacts, and remote contact management.

Thanks for reading and hope this insight was helpful.

Cheers.

Getting Started with Teams Queues App: Features, Voice Application Policy Settings, and Roles

Welcome to the world of Microsoft Teams Queues App! This powerful tool is designed to streamline your team's communication and enhance productivity. In this post, we'll explore the key features of the Teams Queues App, including its intuitive interface and robust functionality. We'll also dive into the Voice Application policy settings and controls, which allow you to manage call routing and user permissions effectively. Additionally, we'll highlight the differences between a Teams Admin Role and the authorized user setting, ensuring you have a clear understanding of the distinct responsibilities and capabilities each role entails. Whether you're an admin or an authorized user, this guide will help you get familiar with the Teams Queues App and get started on the right foot.

Key features provided with Queues App 

Collaborative Calling: Teams working together to service customers can benefit from a shared call queue in a Teams Channel. This feature allows team members to manage calls collectively, ensuring that no customer call goes unanswered

Enhanced user interface: The Teams Queues App offers an intuitive and streamlined user interface, allowing team members to manage customer calls efficiently and enabling team leads to configure call queues and auto attendants directly from the Teams client, enhancing overall productivity and user experience

Real-Time Metrics and Historical Reporting: The app offers real-time metrics such as the number of waiting calls, average wait time, and longest call waiting time. Additionally, it provides historical metrics for call queues and auto attendants, helping teams analyze performance and make data-driven decisions

Enhanced Customer Engagement: By integrating with other Microsoft Teams features, the Queues App allows agents to quickly access subject matter experts within the organization. This immediate access to resources enables agents to resolve customer inquiries more efficiently, leading to improved customer experiences.

Seamless Integration: The app integrates seamlessly with Microsoft Teams, eliminating the need for agents to switch between multiple applications. This integration fosters real-time communication via chat, calls, and video meetings, enhancing collaboration and productivity

These features collectively help teams manage customer engagements more efficiently, streamline workflows, and ultimately enhance overall productivity.

Getting started with the Teams Queues App, there are several prerequisites you need to meet:

• Licensing: Users must have both a Teams Phone and a Teams Premium license. Once a user is licensed for Teams Premium, it can take up to 48 hours for the Queues App to be available in the Teams client. Queue agents can be a member of the queue without the Teams Premium license, but will not have access to the Queues App experience in Teams.
• * No longer needed as Queues App is GA as of October 2024 - Teams Preview Policy - at the time of this post, the Queues App is in Public Preview - review your tenant and user preview settings - Public preview in Microsoft Teams - Microsoft Teams | Microsoft Learn
• Resource Accounts: You need a Resource Account for each Call queue and Auto attendant. These accounts must have a Microsoft Teams Phone Resource Account license
• Admin Permissions: During deployment, a Teams Administrator account  is required to set up Voice Application policies, and authorized users of designated auto attendants and call queues.
• Teams Client: The Queues App is currently supported on Teams desktop and Mac clients, but not on web, mobile, or Virtualized Desktop Infrastructure (VDI) clients
• PowerShell Modules: As with many features and administrative controls, the queues app can be managed in Teams Admin Center or the updates Teams PowerShell module can be used.

Let's break down the differences between the Teams Admin Role and the Authorized User Policy settings for the Queues App and Voice Application Policies.

Teams Admin Role

Teams Admins have comprehensive control over the Teams environment, including the Queues App and Voice Application Policies. Their responsibilities include:

• Creating and Managing Policies: Admins can create, edit, and assign custom Voice Application Policies. These policies control what configuration changes authorized users can make to auto attendants and call queues.
• Full Access to Settings: Admins have full access to all settings related to call queues and auto attendants, including hours of operation, call routing, queue membership, and pre-recorded greetings.
• Delegation of Permissions: Admins can delegate certain permissions to authorized users, allowing them to manage specific aspects of call queues and auto attendants without needing full admin rights.
• Global Policy Management: Admins manage the global, org-wide default policy, which disables all configuration change capabilities for all users unless custom policies are created and assigned.

Authorized User Policy Settings

Authorized Users are designated by Teams Admins to manage specific aspects of call queues and auto attendants. Their capabilities include:

• Limited Configuration Changes: Authorized users can make configuration changes to the auto attendants and call queues they are authorized for. This includes managing business hours, call routing, and viewing real-time and historical metrics.
• No Admin Center Access: Authorized users do not need access to the Teams Admin Center portal nor do they need to be assigned any administrative roles.
• Access Through Teams Client: Authorized users can access and manage their assigned call queues and auto attendants directly through the Teams desktop client or the Queues App.
• Policy Assignment: Authorized users must be assigned a custom Voice Application Policy created by an admin. This policy provides the minimum levels of permissions needed for their role.

Key Differences

• Scope of Control: Teams Admins have full control over all settings and policies, while Authorized Users have limited control based on the permissions assigned to them.
• Access Level: Teams Admins access and manage settings through the Teams Admin Center, whereas Authorized Users manage their assigned settings through the Teams client or Queues App.
• Policy Creation and Assignment: Only Teams Admins can create and assign custom Voice Application Policies. Authorized Users can only operate within the confines of the policies assigned to them.

These distinctions ensure that while Teams Admins maintain overall control and security, Authorized Users can efficiently manage specific aspects of call queues and auto attendants, enhancing productivity and delegation within the organization.

Implementation Planning

We've covered the features and value within the Queues App. In getting started, there are a few recommended planning steps. 

• Assignment of the Teams Premium license - Teams Premium is required to access the queues application, while all queue agents may not require the Queues App interface, assign the Teams Premium add-on (not included in E5).
• App Setup Policy - define which users will see the Queues App and the pinned position of the Queues App (or user pinning allowed)
• Voice Application Policy - define the controls needed for each role or persona
• Authorized users - define non-administrative users who can interact, control and report within each auto attendant or call queue

Premium License Assignment

Teams App Setup Policy

Voice Application Policy

This section offers flexibility and should be planned accordingly. You may consider getting started with 3 policy settings based on persona's. 

• Manager/Supervisor
• Agent
• Reporting Only (no control or interaction with the call flow, visibility of statistics and reporting)

You may also consider additional policies here, and options to separate Auto Attendant functions from Call Queue functions. Often Call Queues are preceded in the call flow by Auto Attendants (nesting) therefor control of both functions may be needed.

Take note - the historical reporting options allow for control over ALL Queues in the tenant or only when authorized users are defined.

Auto attendant and Call queue historical reports - Microsoft Teams | Microsoft Learn

The Queues App interface provides access to real-time and historical reporting, keep in mind these settings also control access to historical reporting in Power BI

I covered this earlier this year in a blog post - Auto Attendant and Call Queue Historical Reporting in Power BI

Assign the policies to users

and

Define Authorized Users

Within each Auto Attendant and Call Queue - define the authorized users who do not have a Teams Administrative role.

As with any cloud solution - it may take time for licenses and policies to propagate down to users so please be patient.

Queues App in Action

Once settings and policies have synchronized the Queues App will be visible (if pinned) on the side bar. Take note of the Auto Attendants and Call Queues across the top and the historical reports available in the upper right corner through Analytics.

Important - Understanding the Queues App and Auto Attendant / Call Queue Settings

While the Queues App provides an enhanced interface for calling, follow-up, agent presence, and call statistics - control over greeting messages, agent selection, and call routing is accessed through the Teams Client settings (for authorized users)

Navigate to Settings -> Calls for administrative controls over each attendant and queue

Note - the small purple icon will identify an Auto Attendant or Call Queue.

Update - the Queues App is now Generally Available as of October 2024.

This guide provides a solid foundation for getting started with the Queues App in Teams. While there are numerous comprehensive contact center integrations available for organizations requiring full-featured experiences or CRM integration, the Queues App combined with Teams Premium offers a valuable solution that bridges the gap between basic queue needs and a fully-featured contact center.

Stay tuned - in the next chapter we will cover specific personas and real-world use of the Queues App.