App content iframe lacks allow="encrypted-media", EME (DRM playback) blocked for all tab/meeting apps

[Nelrohd]

Steps to reproduce

1. Install any tab or meeting app whose content plays DRM-protected video (Widevine/PlayReady via Encrypted Media Extensions). Reproduces in both the new Teams desktop client (WebView2) and Teams on the web, on Windows and macOS.
2. From inside the app's iframe, run:

navigator.requestMediaKeySystemAccess('com.widevine.alpha', [{
  initDataTypes: ['cenc'],
  videoCapabilities: [{ contentType: 'video/mp4; codecs="avc1.64001f"' }],
}]).then(console.log, console.error);

3. The promise rejects with SecurityError before any key system is evaluated. Confirming diagnostic from inside the iframe:

document.featurePolicy.allowsFeature('encrypted-media')  // → false

Root cause: EME is gated by the encrypted-media Permissions Policy feature (default allowlist 'self'). Teams embeds app content in a cross-origin iframe without allow="encrypted-media", so the permission can never be granted from the app side. The same code succeeds when the app origin is loaded in a standalone tab.

Expected behavior

Apps can play DRM-protected media inside Teams. The app-content iframe should include encrypted-media in its allow attribute, either unconditionally, or opt-in via an app-manifest declaration (devicePermissions or a new capability), the same mechanism by which clipboard access was requested and delivered (#3588, OfficeDev/microsoft-teams-library-js#738).

This affects every ISV that needs protected media in Teams (our use case: studio-grade secure content review during meetings, where DRM is contractually required by the content owners). There is no app-side workaround: Permissions Policy delegation is parent-controlled by design, and serving unprotected streams defeats the content-protection requirement.

Actual behavior

navigator.requestMediaKeySystemAccess() rejects with SecurityError for every key system (Widevine, PlayReady), so no DRM-protected content can play in any embedded app surface. document.featurePolicy.allowsFeature('encrypted-media') returns false inside the app iframe.

Error details

[Violation] Permissions policy violation: encrypted-media is not allowed in this document.
Encrypted Media access has been blocked because of a Feature Policy applied to the current document.

[m365-agent-toolkit-assistant]

👋 Hi @Nelrohd,

Thank you for reporting this issue! We want to let you know that:

⏱️ Our team will personally review your issue
🎯 You can expect a response within 1 business day

✨ This is an AI-generated initial response
🤖 AI-Generated Preliminary Analysis:

Classification: Bug — the failure appears caused by Teams host iframe policy, not app code: your repro shows featurePolicy.allowsFeature('encrypted-media') === false, and Teams tabs/meeting apps run inside iframes controlled by the host.

• Teams docs confirm tabs/meeting apps are hosted in iframe elements, so iframe permissions are host-controlled, not app-controlled.
• Teams device-permission docs list supported manifest devicePermissions as only media, geolocation, notifications, midi, and openExternal — no encrypted-media/DRM capability is documented.
• Microsoft Edge docs confirm EME/DRM is supported in the browser generally, which matches your standalone-tab success and points back to Teams embedding policy.

Upgrade check: No documented TeamsJS/toolkit/changelog fix found; this looks platform-side, not app-side.

What to do now:

1. Treat this as a Teams platform gap/bug and track for product-team triage.
2. If DRM is mandatory, use an external browser fallback for protected playback.
3. Ask Microsoft to support allow="encrypted-media" or a manifest-based opt-in.

Useful links:

• No similar issues found in the searched repos.
• https://learn.microsoft.com/microsoftteams/platform/tabs/how-to/tab-requirements
• https://learn.microsoft.com/microsoftteams/platform/concepts/device-capabilities/native-device-permissions#manage-permissions
• https://learn.microsoft.com/legal/microsoft-edge/privacy#digital-rights-management-and-media-licenses

If helpful, I can draft a tighter escalation comment for the Teams product team.

---

Note: This is an automated first response generated by AI. A human team member will review your issue and provide a more detailed response soon. We appreciate your patience!

[Prasad-MSFT]

Thanks for raising your issue. We will check this at our end and will update you accordingly.

[Prasad-MSFT]

Based on feedback from the engineering team, this does not appear to be a known platform limitation. Teams supports media-related permissions through the app manifest, and requesting the appropriate media device permission should result in the required media permissions (including encrypted-media) being added to the iframe allow list when permission is granted.
https://learn.microsoft.com/en-us/microsoftteams/platform/concepts/device-capabilities/native-device-permissions?tabs=mobile%2Cteamsjs-v2%2Cmobile1#specify-permissions

Could you please verify the following:

• The app manifest includes the media device permission.
• The user has granted the required media permission for the app in Teams.
• The issue is reproducible after the media permission has been granted and the app has been reloaded.

[Nelrohd]

Thank you for the suggestion, we tested it, and unfortunately it only partially addresses the issue. Adding "devicePermissions": ["media"] does unblock DRM technically, but only through a manual per-user consent flow that we don't think is viable for a playback-only app, so we'd like to keep this open and explain what we found.

What we tested:

1. We added "devicePermissions": ["media"] to the manifest and re-uploaded the package.
2. The manifest change alone wasn't enough. DRM playback still failed, with the console showing encrypted-media not allowed by Permissions Policy.
3. It only works after each user manually goes to Settings → App permissions → → enable "Media (Camera, microphone, speakers)" and reloads the app.

Why this flow is a real problem for end users:

Our app is a video playback app. It never uses the camera or microphone. So from a non-technical user's point of view, the flow is genuinely confusing: they open the app to watch a video, it doesn't play, and the fix is to find a settings page and grant us "Camera, microphone, speakers" access, for an app that visibly does nothing with a camera or mic. Many users will (reasonably!) hesitate or refuse, assuming something is wrong or that the app is asking for more than it should. We expect this to be a recurring support issue, and since device permissions don't roam across sign-in sessions, users may face it more than once.

The root cause is that encrypted-media is bundled under the media permission, even though EME is playback-only, it doesn't access any capture device or sensor; it's a content-protection API, closer in spirit to autoplay or fullscreen than to camera/microphone.

Would either of these be feasible?

1. Delegate encrypted-media on the app iframe unconditionally. For context, on the open web this is a plain embedder decision, sites add allow="encrypted-media" to cross-origin player iframes (YouTube, Vimeo, etc.) without any user-consent step, because EME isn't a privacy-sensitive capability in the Permissions Policy sense. Teams adding one is a side effect of it sharing the media bucket with camera/microphone, not something the feature itself requires. Or:
2. A dedicated devicePermissions value (e.g. "encryptedMedia") that adds allow="encrypted-media" without the consent gate, so apps that only play protected video never have to ask users for camera/mic-sounding permissions they don't use.

Thank you very much.

[Prasad-MSFT]

@Nelrohd , thank you for the detailed explanation. We are currently checking this with our engineering team and will keep you informed as soon as we have an update.

[Nelrohd]

Hello @Prasad-MSFT, I hope you're doing well. Any update on your side please?

[Prasad-MSFT]

We've communicated this to the engineering team, and they are planning to incorporate the requested changes. We'll keep you informed and notify you as soon as we have any further updates.

[Nelrohd]

Perfect thank you very much @Prasad-MSFT. Let me know if I can be of any assistance meanwhile.