Microsoft Puview - Protect Teams Voicemail in Exchange

Securing sensitive content across platforms is no longer optional—it’s foundational. Microsoft Purview Information Protection offers a unified framework to classify, label, and protect data across Microsoft 365, including Exchange Online. One often-overlooked vector is voicemail: Teams voicemail is stored in Exchange as an email attachment, it becomes subject to the same compliance and security policies as any other message.

By leveraging Purview’s sensitivity labels and auto-labeling policies, organizations can enforce granular controls over voicemail content. This includes the ability to automatically apply encryption and restrict actions such as downloading, saving, or forwarding voicemail messages—ensuring that sensitive voice communications remain contained within the intended compliance boundary. These protections are enforced directly in Outlook clients, while Teams clients are intentionally excluded from accessing protected voicemail, further reducing the risk of data leakage. Message preview is allowed, so the voicemail can be reviewed, the transcription is also provided for preview but the recorded voice can not be downloaded, forwarded or saved.

Before:

After:

Sensitivity label applied - message encrypted - forward, download, copy/paste prevented

Background:

I put this post together for a few reasons. First, and most important - a client needed this solution guidance to align with current security, privacy and compliance rules. Second - there has been changes in Purview and rights management and i found the public documentation lacking, specific to voicemail.

Before we get started, I also wanted to point out the importance for Teams Admin's to include their Exchange Admin and Compliance Admin partners in the conversation. While Teams calling and voicemail is the target for our solution - M365 cloud voicemail "lives" in Exchange, and compliance and data protection rules are configured in Purview so we need all parties involved to reach our goal.

With regard to documentation around Exchange Rights Management and Purview sensitivity labels, much has changed, including the sender IP ranges used for cloud voicemail.

Ingredients:

To accomplish the outcome here we will use:

• Microsoft Purview (available as part of E5 or stand-alone)
• Sensitivity Label
• Auto Label Policy - with 2 rules supporting both internal voicemail recordings and PSTN voicemail recording

Exchange transport rules are not needed for this implementation but recommended to review with Exchange Admins.

Important note - as we are encrypting and securing the voicemail stored in Exchange, this also prevents the Teams client from presenting the voicemail and transcription so that listening to the voicemail, or reviewing the transcript can only be performed from the Outlook client. 

Create a Sensitivity Label for protecting voicemail in Exchange.

Once in the menu for label creation, give your label a name, something specific that helps you identify the purpose and keeps this auto label differentiated from user-assigned labels when sending emails or protecting other file content.

Under scope select emails

Under items select control access - since we wont be applying content marking.

Under access control select assign permissions now, and then proceed to assign permissions selection at the bottom.

Choose the users or groups you wish to protect (keep in mind any selected users or groups will need a Purview license assigned)

And select the specific permissions to control - in my example here, I used the viewer permission which prevents forwarding, download/save, and copy. You could also build custom permissions as needed.

Once saved - you will see users, groups and permissions within the access control menu.

Auto-Labeling we will leave off for now, as we will perform this with an auto-label policy

Skip Groups and Sites - this is an Exchange policy, and proceed to save the label.

Build Auto Label policy to apply to voicemail objects in Exchange.

Next proceed to Auto-labeling policies and create a new policy. Auto-labeling is the method needed to protect voicemail as this is an inbound message, and we would not want users to select and apply their

Give the auto-label policy a name, and on the label screen, then select the sensitivity label created in the previous step.

Admin Units can be left default to Full Directory, we selected applicable users and groups which apply to the specific users and groups targeted for the label itself.

Select Exchange Email as the target

Exchange Rules is where the magic happens, to ensure we are labeling and securing voicemails, and not other unintended email. For those familiar with Exchange transport rules, this will be a familiar exercise.

In this section, create 2 rules with 2 conditions in each rule. The rules are treated as "OR" so if either rule is matched the sensitivity label is applied. Within a rule, the conditions to be matched are treated as "AND" - so 2 rules are needed to support the "OR" condition.

The first rule, designed to capture external/PSTN calls who recorded voicemail for users, we define the senders address. PSTN calls which present a phone number, result in voicemail from noreply@skype.voicemail.microsoft.com.

Content-Class=Voice-CA allows us to select an additional message header condition to ensure we label voicemails.

The second rule is targeted to label internal voicemail, when called from a user inside the tenant. In this example because the caller identity is know to the tenant and Exchange, the sender name is the caller and not noreply@skype.voicemail.microsoft.com. Here we use the domains known to the tenant as the sender domain. (Your tenant domain names)

Often these rules, whether in Exchange Transport or Purview Sensitivity Labels are written with sender IP address conditions, in an attempt to ensure accurate rule processing based on voicemail entry into exchange. In my testing and implementation I could not find one complete set of IP sender addresses to incorporate voicemail filtering, so I chose to use sender/domain name with header Content-Class=VoiceCA. Sensitivity auto-label rules require a sender or IP address condition to be met in order to provide the additional header filter (ie. you cant apply a "header contains" filter only).

Next replace any existing labels, and apply encryption with a rights management owner. 

Note on this final step - policy mode is set to simulation only. Enable the policy after 7 days of simulation or once the policy is saved, activate immediately.

DONE !!

To report on auto-label success rates, in the Purview portal, select Explorers -> Activity Explorer and filter for the newly created label to view a chart and report of all label activities.

Some additional tips, review message headers to fine tune or adjust your label criteria if desired. If Exchange transport rules are already configured (example below) Rights Protection, this rule is processed before the message gets to Purview, and will replace the Content-Class header with rpmsg.message. When this happens, while the message may be rights protected, the Purview label and rules are not applied because the Content-Class header does not match - consider turning off Exchange Transport rules for protection and encryption purposes and leveraging Purview, or update the auto-label policy to include a rule that also looks for rpmsg.message.

Exchange message trace can help ensure the label is being applied, or provide insight to why the message may not be evaluated.

Just one last reminder - with this implementation users will listen (preview) their recording or review the transcript in Outlook, and be able to see there was a missed call, and recorded voicemail in Teams, but not be able to listen from the Teams client ... if your organization is needing to secure recorded voicemail - this guide will help.

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.