Microsoft Edge UserDataDir policy: How to verify effective policy before launching an isolated browser instance?

Question

Microsoft Edge UserDataDir policy: How to verify effective policy before launching an isolated browser instance?

海林 0

We are preparing a controlled test that launches a single Microsoft Edge instance on Windows 11 with a newly created, empty user-data directory specified through the --user-data-dir command-line argument.

Our primary concern is ensuring that the test browser cannot accidentally access or reuse an existing personal Edge profile.

We understand that the Microsoft Edge UserDataDir enterprise policy, when enabled, can override the --user-data-dir command-line argument.

Checks already performed:

The existing personal Edge instance shows no configured policies in edge://policy.

A restricted Windows child process was used to check the Edge policy registry locations under HKCU and HKLM, including 32-bit and 64-bit views.

No UserDataDir policy was found in those checked registry locations.

We recognize that these observations do not conclusively establish the final effective policies for a future Edge instance.

The proposed test browser has not been launched.

Questions:

Is there a Microsoft-supported method to determine the final effective UserDataDir policy for a specific Windows execution identity before launching Edge?

How can we reliably check for policy overrides originating from Group Policy, MDM, or Edge cloud management?

If complete pre-launch policy verification is not possible, is there a supported isolation mechanism that guarantees a new Edge instance cannot access an existing personal Edge user-data directory, without weakening existing security controls?

What evidence is sufficient to verify that an Edge instance uses the intended independent user-data directory? In particular, what are the limitations of checking edge://version, the process command line, and the browser's reported Profile Path after startup?

Our concern is that a post-launch verification alone may be insufficient if an unexpected policy redirects Edge to an existing profile during startup.

We would appreciate guidance based on Microsoft Edge's documented policy behavior and supported isolation mechanisms.We are preparing a controlled test that launches a single Microsoft Edge instance on Windows 11 with a newly created, empty user-data directory specified through the --user-data-dir command-line argument.

Our primary concern is ensuring that the test browser cannot accidentally access or reuse an existing personal Edge profile.

We understand that the Microsoft Edge UserDataDir enterprise policy, when enabled, can override the --user-data-dir command-line argument.

Checks already performed:

The existing personal Edge instance shows no configured policies in edge://policy.

A restricted Windows child process was used to check the Edge policy registry locations under HKCU and HKLM, including 32-bit and 64-bit views.

No UserDataDir policy was found in those checked registry locations.

We recognize that these observations do not conclusively establish the final effective policies for a future Edge instance.

The proposed test browser has not been launched.

Questions:

Is there a Microsoft-supported method to determine the final effective UserDataDir policy for a specific Windows execution identity before launching Edge?

How can we reliably check for policy overrides originating from Group Policy, MDM, or Edge cloud management?

If complete pre-launch policy verification is not possible, is there a supported isolation mechanism that guarantees a new Edge instance cannot access an existing personal Edge user-data directory, without weakening existing security controls?

What evidence is sufficient to verify that an Edge instance uses the intended independent user-data directory? In particular, what are the limitations of checking edge://version, the process command line, and the browser's reported Profile Path after startup?

Our concern is that a post-launch verification alone may be insufficient if an unexpected policy redirects Edge to an existing profile during startup.

We would appreciate guidance based on Microsoft Edge's documented policy behavior and supported isolation mechanisms.

0 comments

1 answer

Your answer

Answer 1

No Microsoft-supported pre-launch method is documented to compute the final effective UserDataDir for a future Edge process on Windows.

Supported facts from the documented behavior are:

If the UserDataDir policy is enabled, Microsoft Edge uses the policy-specified directory regardless of the --user-data-dir command-line flag.
If the policy is not enabled, Edge uses the default profile path, but the user can override it with --user-data-dir.
On Windows, the policy is stored at HKLM\SOFTWARE\Policies\Microsoft\Edge with value name UserDataDir and type REG_SZ.
The supported in-browser verification method is edge://policy, which shows applied policies after Edge is running.
The current profile path can be checked in edge://version under Profile path after startup.
Policy refresh for Edge is not dynamic for UserDataDir; a browser restart is required.

Based on that, the supported verification path is post-launch, not pre-launch:

Launch Edge with the intended --user-data-dir value.
Open edge://policy and verify whether UserDataDir is applied.
Open edge://version and verify the reported Profile path.
If policy was recently changed through Group Policy, run gpupdate /force, then close and reopen Edge before validating.
If checking Windows policy storage directly, inspect HKLM\SOFTWARE\Policies\Microsoft\Edge.

What can be concluded from the evidence:

edge://policy is the supported way to see policies that are actually applied to the running browser.
edge://version is the supported way to see the profile path the running browser is using.
A command line containing --user-data-dir is not sufficient by itself, because the documented policy behavior says UserDataDir overrides that flag when enabled.
Checking only the registry path is not sufficient to prove the final effective state of a future instance, because the documentation provided only states where Windows policy settings are stored and how to view applied policies after launch.

For policy origins:

Group Policy: supported checks are gpupdate /force, the registry path HKLM\SOFTWARE\Policies\Microsoft\Edge, and edge://policy after launch.
MDM and Edge cloud management: no supported pre-launch verification method for UserDataDir is documented in the provided material.

For isolation before first launch:

No supported isolation mechanism is documented here that guarantees a future Edge instance cannot access an existing personal Edge user-data directory before startup evaluation occurs.
The only documented control in scope is the UserDataDir policy itself and post-launch verification through edge://policy and edge://version.

Limitations of the checks mentioned:

Process command line: not authoritative for effective user data location when UserDataDir policy is enabled.
edge://version / Profile path: authoritative for the running instance’s current profile path, but only after startup.
edge://policy: authoritative for policies applied to the running instance, but only after startup.

If the requirement is absolute proof before any Edge startup, that proof is not documented in the provided Microsoft Edge guidance. The documented, supported evidence is the combination of edge://policy and edge://version on the launched instance, with Windows policy inspection and gpupdate /force used as supporting checks.