Manage camera, microphone, and location access for desktop apps

  • Applies to: ✅ Windows 11, version 24H2 and later

Windows now provides granular privacy controls for unpackaged desktop (Win32) applications to manage Camera, Microphone, and Location access. As an IT administrator, you can preconfigure whether a specific app is allowed or denied access to each capability, and whether unsigned apps are allowed or denied outright.

This article explains how to deploy those policies across managed Windows devices by using Microsoft Intune. Configure policies independently for Camera, Microphone, and Location.

Note

Packaged desktop apps use the existing Package Family Name policies (_ForceAllowTheseApps, _ForceDenyTheseApps, _UserInControlOfTheseApps) rather than the namespace lists described in this article.

Why these policies matter

Without enterprise policies, users can be prompted when desktop apps request access to Camera, Microphone, or Location. Across a device fleet, that behavior produces more consent prompts, more help desk volume, inconsistent user decisions, and limited administrative control over privacy-sensitive capabilities.

By using per-app enterprise policies, you can:

  • Preapprove trusted apps so they're allowed silently.
  • Predeny unapproved apps so they're blocked silently.
  • Allow or deny all unsigned apps for a capability, independent of any app-specific list.
  • Apply consistent Camera, Microphone, and Location policies across managed devices.
  • Deploy through existing Microsoft Intune infrastructure.
  • Let apps that don't match an Allow or Deny list continue to follow existing Windows privacy behavior.

How it works

When a desktop app requests access to Camera, Microphone, or Location, Windows evaluates the app's identity and checks it against your configured policies.

1. Windows determines the app's namespace value

Windows generates a namespace value for signed apps. This value is what you retrieve and use in policy. See Find the app's namespace value.

This value isn't guaranteed to stay fixed. See When an app's namespace value changes.

2. Windows evaluates the configured policies

Windows compares the namespace value against the Force Allow and Force Deny lists configured for the requested capability.

3. Windows applies the matching policy

  • If the namespace value matches a Force Deny list, Windows blocks access silently.
  • If the namespace value matches a Force Allow list and no higher-priority policy denies access, Windows grants access silently.

4. Windows applies fallback behavior

If no higher-priority policy determines the result and the namespace value doesn't appear in either list, Windows falls back to:

  1. The applicable global LetAppsAccess* enterprise policy, if one is configured
  2. Device-wide and user-wide privacy settings, if no applicable enterprise policy determines the result
  3. Existing per-app user consent, if permitted by the higher-level settings

Unsigned apps

If an app isn't signed, or its signature isn't valid, Windows doesn't generate a namespace value for it, so app-specific Allow and Deny lists have no effect. Instead, Windows checks the unsigned-app policy for the requested capability:

  • If Force Deny Unsigned is configured, all unsigned apps are blocked from that capability.
  • If Force Allow Unsigned is configured, all unsigned apps are allowed for that capability.
  • If neither is configured, Windows falls back to the global policy or existing consent state.

App-specific policies and unsigned-app policies are evaluated independently. You can configure one, both, or neither for any capability.

Policy precedence and configuration conflicts

Don't place the same namespace value in both the Force Allow and Force Deny lists for the same capability.

If the same value is present in both lists, Force Deny takes precedence and access is blocked. This rule provides a fail-closed result when conflicting policies are configured. The same rule applies to unsigned apps: if both Force Allow Unsigned and Force Deny Unsigned are configured for a capability, denying unsigned apps wins.

Remove conflicting entries as soon as you identify them so the intended policy stays clear and auditable.

Policy evaluation follows this order:

  1. Matching Force Deny value (app-specific, or Force Deny Unsigned for unsigned apps)
  2. Matching Force Allow value (app-specific, or Force Allow Unsigned for unsigned apps)
  3. Applicable global LetAppsAccess* policy
  4. Existing per-app user consent state

Warning

Deny takes precedence. Before deploying policies broadly:

  • Audit all Force Allow and Force Deny lists to make sure no namespace value appears in both.
  • Test policies in a limited validation group first.
  • Verify that critical trusted apps aren't unintentionally blocked by a conflicting Deny entry.
  • Document your Allow and Deny decisions for future reference and compliance.

Prerequisites

  • Windows 11, version 24H2 or later
  • Microsoft Intune for policy deployment
  • Event Viewer access on a device where the target app is installed
  • For app-specific policies, a valid, signed copy of the app installed on a test device

You can only control unsigned apps through the unsigned-app policies. You can't match them individually.

Step 1: Find the app's namespace value

Before creating a policy, retrieve the namespace value for each app you want to allow or deny. Do this step once per app. The same value applies across Camera, Microphone, and Location, so you don't need to repeat it for each capability.

  1. Install the app on a test device.

  2. Use the app to access one of the capabilities it needs (camera, microphone, or location) at least once, so Windows records a consent-state event.

  3. Open Event Viewer. Select Win+R, then enter eventvwr.msc.

  4. Go to Applications and Services Logs > Microsoft > Windows > Privacy-Auditing > Operational.

    This log can be hidden by default. If you don't see it, go to View > Show Analytic and Debug Logs.

  5. This log also records other consent and capability-access activity from across Windows, so don't assume the entry you want is the newest one in the list. Use Find (Ctrl+F) or Filter Current Log to search for the app's file path, and locate the entry for the capability you just used.

  6. Open that event and copy the value labeled namespace.

Use this value exactly as shown. Don't trim, reformat, or reconstruct it.

Step 2: Choose the policy values

Windows provides separate Force Allow and Force Deny policies for each supported capability, plus separate Force Allow and Force Deny policies for unsigned apps.

Camera

  • LetAppsAccessCamera_ForceAllowTheseNamespaces
  • LetAppsAccessCamera_ForceDenyTheseNamespaces
  • LetAppsAccessCamera_ForceAllowUnsigned
  • LetAppsAccessCamera_ForceDenyUnsigned

Microphone

  • LetAppsAccessMicrophone_ForceAllowTheseNamespaces
  • LetAppsAccessMicrophone_ForceDenyTheseNamespaces
  • LetAppsAccessMicrophone_ForceAllowUnsigned
  • LetAppsAccessMicrophone_ForceDenyUnsigned

Location

  • LetAppsAccessLocation_ForceAllowTheseNamespaces
  • LetAppsAccessLocation_ForceDenyTheseNamespaces
  • LetAppsAccessLocation_ForceAllowUnsigned
  • LetAppsAccessLocation_ForceDenyUnsigned

App-specific policies use data type String and hold one or more namespace values. Separate multiple values with semicolons:

4028cad637509d4744b17ec5b42aed8d7a31e6a0;5139dbe748610e5855c28fd6c53bf9e8b42f2f7b

Don't include app names, file paths, or any allow or deny state text. The value is the namespace string or strings only. Matching is case-insensitive, but spaces aren't trimmed, so don't add spaces around separators. Wildcards such as * aren't supported.

Unsigned-app policies use data type Integer and take 1 to enforce or 0 to leave disabled.

The policy node you select (Force Allow or Force Deny) determines whether matching apps, or for unsigned policies all unsigned apps, are allowed or denied.

Step 3: Deploy the policies through Microsoft Intune

Create a configuration profile

In the Microsoft Intune admin center:

  1. Go to Devices.
  2. Select Configuration profiles.
  3. Select Create profile.
  4. Configure the profile:
    • Platform: Windows 10 and later
    • Profile type: Templates
    • Template: Custom
  5. Name and describe the profile, for example:
    • Name: Desktop App Privacy Controls
    • Description: Camera, Microphone, and Location access policies for desktop apps

Add OMA-URI settings

Create a separate setting for each capability and action your organization wants to configure.

Capability Setting OMA-URI Data type
Camera Allow these apps ./Device/Vendor/MSFT/Policy/Config/Privacy/LetAppsAccessCamera_ForceAllowTheseNamespaces String
Camera Deny these apps ./Device/Vendor/MSFT/Policy/Config/Privacy/LetAppsAccessCamera_ForceDenyTheseNamespaces String
Camera Allow unsigned apps ./Device/Vendor/MSFT/Policy/Config/Privacy/LetAppsAccessCamera_ForceAllowUnsigned Integer
Camera Deny unsigned apps ./Device/Vendor/MSFT/Policy/Config/Privacy/LetAppsAccessCamera_ForceDenyUnsigned Integer
Microphone Allow these apps ./Device/Vendor/MSFT/Policy/Config/Privacy/LetAppsAccessMicrophone_ForceAllowTheseNamespaces String
Microphone Deny these apps ./Device/Vendor/MSFT/Policy/Config/Privacy/LetAppsAccessMicrophone_ForceDenyTheseNamespaces String
Microphone Allow unsigned apps ./Device/Vendor/MSFT/Policy/Config/Privacy/LetAppsAccessMicrophone_ForceAllowUnsigned Integer
Microphone Deny unsigned apps ./Device/Vendor/MSFT/Policy/Config/Privacy/LetAppsAccessMicrophone_ForceDenyUnsigned Integer
Location Allow these apps ./Device/Vendor/MSFT/Policy/Config/Privacy/LetAppsAccessLocation_ForceAllowTheseNamespaces String
Location Deny these apps ./Device/Vendor/MSFT/Policy/Config/Privacy/LetAppsAccessLocation_ForceDenyTheseNamespaces String
Location Allow unsigned apps ./Device/Vendor/MSFT/Policy/Config/Privacy/LetAppsAccessLocation_ForceAllowUnsigned Integer
Location Deny unsigned apps ./Device/Vendor/MSFT/Policy/Config/Privacy/LetAppsAccessLocation_ForceDenyUnsigned Integer

Assign the profile

Assign the profile to the required Microsoft Entra device or user groups based on your organization's deployment plan. Deploy to a limited validation group before assigning broadly.

Example configurations

These examples assume no higher-priority restriction applies.

Example 1: Allow an app to access camera and microphone

Look up the app's namespace value once, then apply it to each capability.

Camera Force Allow:

4028cad637509d4744b17ec5b42aed8d7a31e6a0

Microphone Force Allow:

4028cad637509d4744b17ec5b42aed8d7a31e6a0

Location isn't configured in this example, so the app's location access follows the applicable fallback behavior.

Example 2: Allow one app and deny another

Camera Force Allow:

4028cad637509d4744b17ec5b42aed8d7a31e6a0

Camera Force Deny:

5139dbe748610e5855c28fd6c53bf9e8b42f2f7b

The first app is silently allowed camera access. The second is silently denied.

Example 3: Allow multiple apps

Separate multiple namespace values with semicolons in the same Force Allow policy:

4028cad637509d4744b17ec5b42aed8d7a31e6a0;5139dbe748610e5855c28fd6c53bf9e8b42f2f7b;62410ec859721f6966d3af07d76e0f9d64a3141c

Example 4: Require all location apps to be signed

LetAppsAccessLocation_ForceDenyUnsigned: 1

All unsigned apps are blocked from location access. Signed apps are still evaluated against your app-specific policies, or fall back to your global setting if none is configured.

Example 5: Block unsigned apps but allow one trusted app

LetAppsAccessCamera_ForceDenyUnsigned: 1
LetAppsAccessCamera_ForceAllowTheseNamespaces: 4028cad637509d4744b17ec5b42aed8d7a31e6a0

LetAppsAccessMicrophone_ForceDenyUnsigned: 1
LetAppsAccessMicrophone_ForceAllowTheseNamespaces: 4028cad637509d4744b17ec5b42aed8d7a31e6a0

All unsigned apps are blocked from camera and microphone. The named app is allowed for both. Location is left unrestricted in this example.

Each capability is managed independently. Adding an app to the Camera policy doesn't apply it to Microphone or Location.

Validation and troubleshooting

Confirm the namespace value

On a test device, repeat the Event Viewer lookup in Step 1 and confirm that:

  • The value matches what you configured in Intune exactly, with no extra spaces or truncation.
  • The event is for the correct app and the correct capability.
  • The value isn't unintentionally present in both the Force Allow and Force Deny lists.

Policy isn't applied

Verify that:

  • You assigned the Intune configuration profile to the expected group.
  • The target device received the profile.
  • The OMA-URI uses the correct capability and policy name.
  • App-specific policies use data type String, and unsigned-app policies use Integer.
  • You separated multiple namespace values with semicolons, with no extra spaces.
  • You're testing the policy on Windows 11, version 24H2 or later.

Users still receive prompts

A user can still see a prompt if:

  • The app's namespace value doesn't match a configured Force Allow or Force Deny entry, so Windows falls back to the global policy or existing consent state.
  • The app is unsigned, and you didn't configure an unsigned-app policy.
  • The configured policy applies to a different capability than the one being requested.
  • A different binary or component is performing the access. Some apps use multiple executables, shared system components, or browser-hosted processes. Ensure you're triggering the capability from, and retrieving the namespace value for, the binary that actually requests access, not just the app's main executable.

Access is unexpectedly denied

Verify that:

  • The namespace value isn't present in the applicable Force Deny list.
  • The same value isn't present in both the Force Allow and Force Deny lists, because Force Deny always wins.
  • The applicable global LetAppsAccess* policy isn't separately set to deny.
  • You're not testing against an unsigned-app Force Deny policy when the app in question is unsigned.

When an app's namespace value changes

A namespace value isn't guaranteed to stay fixed. If a publisher ships an updated version of an app that changes how it's signed, the namespace value can change and no longer match your existing policy entries.

When you roll out an app update:

  1. Re-run the lookup in Step 1 against the updated app on a test device.
  2. Compare the new value to what's currently configured in policy.
  3. If it changed, add the new value to the relevant policies before the update is broadly deployed.
  4. Keep the old value in place while both the old and new versions remain in use in your environment.
  5. Remove the old value once the earlier version is fully retired.

As a general practice, re-verify namespace values whenever you push a significant update to an app you have app-specific policies configured for.

Known limitations

App-level scope

Eligible unpackaged apps signed with the same certificate share the same namespace value. An Allow or Deny entry applies to all of those apps, not just the executable used to collect the value. Test the specific binaries your users run rather than assuming behavior based on the app name alone.

Unsigned or invalid signatures

If an app is unsigned or its signature is invalid, Windows doesn't generate a namespace value for it. App-specific policies have no effect, and access is governed by the unsigned-app policy, if configured, or the applicable fallback behavior.

Shared and intermediary components

Some apps use shared system components, browser-hosted processes, or intermediary binaries to access a capability. The identity Windows evaluates can belong to the component performing the access rather than the app's primary executable.

Process injection

An app-specific policy identifies the process requesting access when you sign and launch it. It can't distinguish code injected into that process after launch from the app's original code.

These policies don't replace app control tools

These settings only govern Camera, Microphone, and Location access. They don't restrict which apps can run on a device, and they aren't a substitute for code-signing enforcement or application control policies.

Deployment recommendations

Before broad deployment:

  1. Inventory the apps in your environment that need Camera, Microphone, or Location access.
  2. Retrieve each app's namespace value by using the Event Viewer method in Step 1.
  3. Build separate Allow and Deny lists for each capability.
  4. Confirm no namespace value appears in both lists for the same capability.
  5. Decide whether to broadly allow or deny unsigned apps per capability.
  6. Deploy to a limited validation group.
  7. Validate Allow, Deny, and fallback behavior on that group.
  8. Expand deployment according to your organization's rollout plan.
  9. Re-verify namespace values when apps you manage receive significant updates.

Related content

  • Last updated on