Credential isolation has a defined scope

Three claims that need different evidence

Credential Guard uses virtualization-based security to support credential isolation: protecting selected authentication secrets from the ordinary operating-system environment. Its supported scope includes certain domain authentication material. It does not automatically protect every password, application key, or locally stored secret.

Separate “policy requests protection,” “protection is running,” and “this secret is covered.” Requirements depend on supported hardware, software, and configuration. A fleet policy value answers only the first question unless the report explicitly includes reliable runtime evidence.

Supplied fleet snapshot

A separate application review finds a usable application key in a normally readable configuration file on B. Assume the observation is accurate and the key is an ordinary application-managed secret, not one of the authentication secrets isolated by Credential Guard. No evidence of its use is provided.

Report protection within its scope

For A, record configured intent with operating state unverified. For B, record verified Credential Guard operation while opening a separate application-secret handling review. The second finding does not prove that isolation failed or that the feature has no value. It identifies a different boundary.

Ask the platform owner for supported-state evidence and the application owner for required readers and a protected secret lifecycle. Compatibility also matters: applications relying on unsupported authentication behavior may need changes. Acceptance should retain required sign-in workflows while demonstrating the intended protection. Avoid a blanket “all credentials safe” label that hides both deployment gaps and documented exclusions.