Limiting Microsoft 365 Copilot data exposure risk with Zero Trust apps and data controls
Learn how to reduce Microsoft 365 Copilot data exposure risks by governing what Copilot can reach after a user is authenticated. This post maps key Layer 2 risks to Zero Trust apps and data controls, including oversharing reduction, sensitivity labeling, DLP, connector governance, audit visibility, and privileged access management.Teams for iOS (MAM only Call Identification)
In order of the implementation of O365/M365 and with it Microsoft Intune, Teams and Outlook for iOS has become the standard collaboration and mail clients on iOS devices for many customers today. This is due to the excellent user experience and the constant stream of new features implemented by Microsoft. From a security perspective, in addition to the provision on managed devices (managed by Intune), the secure use on unmanaged devices with MAM or App Protection Policies (APP) is a big argument for using Teams and Outlook for iOS. A big pain point for many users who use Teams and Outlook for iOS in an MAM-only setup (and for MDM setup with Intune too) is the missing caller identification of Exchange Online (EXO) contacts, when someone is calling via a cellular connection. Outlook for iOS supports a one-way contact export process whereby contacts from within Outlook for iOS can be exported into the personal (unmanaged) part of the native iOS Contacts app. This means a contact must first be imported into the users personal contacts directory of EXO and then exported from Outlook for iOS to the native (unmanaged) iOS Contact app in order to see who is calling. This functionality enables Caller-ID, iMessage, and FaceTime integration for users’ Outlook contacts. The exported Outlook contacts are considered unmanaged and are accessible by unmanaged, personal apps. Especially for European customers who are subject to GDPR compliance, this is a no go, as personal data and company data must not be mixed. The unintentional outflow of contact data worthy of protection to commercial platforms, such as WhatsApp or Google, and the unintentional synchronization of address books with social media apps, represents a significant GDPR risk. Although the user's personal EXO contacts can be synchronized, there is currently no option to synchronize the GAL. Furthermore, there is currently no provision in Teams and Outlook for iOS to synchronize the GAL cyclically. The user has to add a GAL contact to his personal contacts as described above and then within the Outlook for iOS app export the contact to his native iOS contacts app to be able to see who is calling. To meet the GDPR compliance, we need to prevent the contact export. So this is not a solution. The question to ask is: Why does a user need to export a GAL/personal contact to their native iOS Contact app? There are already several paid app solutions that close exactly this gap (ebf Contacts, Secure Contacts, etc.) which offer more or less the same range of functions. The app builds a container and downloads the managed address books (GAL, personal) of the user and then enables the resolution of the CallerID or identification of the caller via the so-called Apple CallKit integration. Apple has been offering the so-called CallKit integration for years. With CallKit you can integrate your calling services with other call-related apps on the system. CallKit provides the calling interface, and you handle the back-end communication with your VoIP service. For incoming and outgoing calls, CallKit displays the same interfaces as the Phone app, giving your app a more native look and feel. CallKit also responds appropriately to system-level behaviors such as Do Not Disturb. In addition to handling calls, you can provide a Call Directory app extension to provide caller ID information and a list of blocked numbers associated with your service. When a phone receives an incoming call, the system first consults the user’s contacts to find a matching phone number. If no match is found, the system then consults your app’s Call Directory extension to find a matching entry to identify the phone number. This is useful for applications that maintain a contact list for a user that’s separate from the system contacts, such as Teams and Outlook for iOS. For example, consider a user who is a colleague to Jane, but doesn’t have her phone number in their contacts. If the Teams or Outlook for iOS app has a Call Directory app extension, which downloads and adds the phone numbers of all of the user´s colleagues. When the user gets an incoming call from Jane, the system displays something like “(App Name, e.g. Outlook) Caller ID: Jane Appleseed” rather than “Unknown Caller”. The effort to integrate the Call Directory Extension is minimal and would solve many pain points from both a security and user experience perspective. Apple has documented CallKit excellently on the developer site: https://developer.apple.com/documentation/callkit With the possibility of using Apple CallKit in combination with Teams and Outlook for iOS and the contact synchronization (personal/GAL) of a managed EXO mailbox, the use of M365 in a BYOD scenario for customers Blue Collar workers will massively increase. Furthermore, the use of contact synchronization is then also possible for devices managed by Intune. This creates an outstanding user experience while increasing user adoption! This article was also published as feedback in the Outlook Forum for iOS: https://feedbackportal.microsoft.com/feedback/idea/a80414f4-9598-ed11-a81b-000d3ae32cd0 There are already other requests within the Microsoft community that I would like to link here: @PatrickF11 : Outlook for iOS + Caller Identification - Microsoft Community Hub Daniel Huttenlocher: https://feedbackportal.microsoft.com/feedback/idea/bbfc8763-da97-ed11-a81b-000d3ae32cd0Upcoming June 2026 Microsoft 365 Champion community call
Join our next community call on June 23, 2026, to explore Microsoft 365 Copilot Cowork and learn how it can really help you get stuff done. Reminder: Our community calls are in the Teams webinar format, so you must register to receive the link to join. The join link will be sent to you in email with your webinar registration confirmation. https://aka.ms/M365ChampionCallAM https://aka.ms/M365ChampionCallPM The calls will still start at 5 minutes past the hour for both sessions (at 8:05 AM and 5:05 PM PT), and it will still end at the top of the hour (9:00 AM and 6:00 PM PT, respectively). While our calls are open to everyone, you must be a member of the Microsoft 365 Champion Program in order to access the presentation materials - the access link is in the initial welcome email and the monthly newsletter emails sent the week before the community calls. An on-demand recording will still be available on our Driving Adoption > Events pages, as well as on our Microsoft Community Learning YouTube channel. If you have not yet joined our Champion community, sign up here to get access to the monthly newsletters, calendar invites, and program assets (e.g., the presentations).
Enhancements wanted for Viva Engage Event Experience
In the Event tab within Viva Engage Communities it would be great with some improvements to enhance the usage and customization of Events. Similar to Facebook and Workplace events where participants had the possibility to select "Attending" and "Not attending". We have cases where we plan in person events where it would be really helpful to get an overview of participants that are attending. Similar to Facebook and Workplace events where participants had the possibility to select "Attending" and "Not attending". Additionally, giving users the ability to add events directly to their calendars would help them stay organized and maintain a better overview of company activities. To summarize very wanted features are: The options for participants to click Attending/Not attending. Option to "Add to Calendar" directly from the event page The ability to mark the event as In Person Is this on Microsoft's Roadmap for enhancements, or could it be considered for future updates?
Microsoft 365 Copilot on mobile: What staged rollout plans can miss
IT teams often design rollout plans in careful stages: the right pilot group, the right prerequisites, the right communications, and the right guardrails. Sequencing matters. But when Microsoft 365 Copilot on mobile shows up in your environment, the shape of adoption can change. Employee behavior doesn’t always follow the same tidy stages as licensing or deployment plans. Once people can use Copilot in the moments where work actually happens—between meetings, on the go, in a hallway conversation, before a customer call—usage can spread faster, more socially, and less linearly than many rollout models assume. You can stage the rollout, but you can’t always stage the real-world usage pattern that follows. And mobile is one of the fastest places that gap shows up. What we’re seeing: mobile changes the moments where Copilot shows up Mobile shifts adoption because it changes the context in which Copilot appears day to day: Copilot shows up more during “in-between” work moments Those moments where people look for quick help: summarizing, drafting, finding, checking, and preparing. Usage spreads through behavior, not just rollout sequence A teammate shares a faster way to prep for a meeting. A leader asks for a quick recap while traveling. A project team starts referencing Copilot outputs in a chat thread. That kind of spread can move ahead of your staged plan. Desktop assumptions don’t always carry over cleanly Governance, communication, and readiness decisions that feel straightforward in a desktop-first mindset can surface earlier when usage starts in mobile-first ways. Taken together, mobile introduces a second force into staged rollout planning: behavioral adoption momentum that doesn’t always wait for the next planned phase. Staged Copilot deployment ≠ staged usage Mobile frequently compresses the “pilot → expand → scale timeline,” creating earlier-than-expected issues: IT starts fielding questions about “what’s allowed,” “what’s recommended,” or “what’s safe” before the plan anticipated Governance and communication become tightly linked. If the org hasn’t expressed expectations and guardrails early and clearly, fast-moving usage can create confusion or conflicting local norms Rollout plans start competing with reality. Mobile can make Copilot feel “present” in daily work. While IT is still staging rollout, parts of the organization behave like they’re already in broader adoption. In many environments, this doesn’t stay theoretical for long. What to do: four areas that tend to matter most If you’re planning your Copilot rollout, you’ll want to think through these four connected areas: Rollout sequencing: how you stage availability and expansion User behavior expectations: how adoption may spread, and how you’ll message it Governance and readiness considerations: what needs to be clear before usage accelerates Communication planning: how you set expectations so momentum doesn’t create confusion If you’re hearing early signals that people are experimenting with Copilot in mobile contexts before the rollout has fully caught up or already seeing pockets of usage spreading faster than expected, use these four as levers for regaining clarity and alignment Next step Read the full blog for Microsoft 365 Copilot mobile rollout planning guidance, including how to align sequencing, governance, and communication, whether you’re still designing your rollout approach, or already responding to early signs of faster-than-expected adoption. Read the full Accelerator blog: Microsoft 365 Copilot on mobile: Planning guidance for IT admins
Regarding Teams Meeting Media Transport Behavior in VDI Optimization Scenario
Hello Microsoft Teams Engineering Team, I am currently working on a Browser Content Redirection / media offload implementation for a VDI environment, where WebRTC media transport is handled through a local native component while the Teams application continues running inside the virtual desktop session. While testing, I observed that: 1:1 calls successfully receive audio and video media But in meetings auido / video RTP is never forwarded despite successful ICE, DTLS, and SRTP establishment DTLS ApplicationData traffic is present during meetings, suggesting DataChannel/SCTP activity Based on transport-level observations, it appears that Teams meetings may rely on SCTP/DataChannel communication for SFU video subscription management, while 1:1 calls do not require the same subscription flow. I wanted to ask whether: Teams meeting video forwarding depends on active bidirectional SCTP/DataChannel connectivity Meeting video subscriptions are expected to be coordinated over the WebRTC data channel/control plane Split ownership of media transport and control-plane transport could affect expected Teams meeting behavior in VDI optimization scenarios Thank you for your time and guidance. Best regards,Rajdev
