We have fixed this on our computers.

TLDR: Enable Secure Launch Configuration under device guard and ensure Enhanced Sign-in Security is also enabled in WHfB settings. Recreate WHfB pin one more time with both settings enabled, no further problems

Cause in our case

Every 4 hours, the MDM enrollment process runs scheduled task 'Schedule #3 created by enrollment client' which applied the settings in C:\Windows\Provisioning\Packages\SecureStart.Settings.ppkg; this included enabling Secure Launch Configuration. If the WHfB pin is not originally set up with secure launch configuration enabled, it returns the 7002 container load error.

Our GPO settings would disable Secure Launch Configuration again every 90 minutes.

WHfB pin would be intermittnetly unavailable if staff rebooted or shutdown between the time the scheduled task ran and GPO re-disabled it

Our long-term fix

Enabled Device Guard-->Secure Launch Configuration and WHfB --> Enable ESS in GPO for all computers; any unsupported hardware just ignores the settings, so no impact.

@Holibur Man @pengcheng yue I have a couple of updates

I finally have a Microsoft support case for on-prem Windows open, though it's being bounced around to find the correct team for it.

We have determined a work-around that has lasted so far - about a week on a test computer. We turned off Trusted Execution Technology (TXT) in BIOS and have not had a repeat WHfB 7002 pin error on that computer. The test computer is being rebooted every 5 minutes via a scheduled task that stops when a 7002 error is seen.

Working with HP support, we've found a difference in the Device Guard SecurityServicesRunning state between successful and failed WHfB boots. Most importantly, the difference was observed on the same computer, TESTCOMPUTER2, between consecutive boots without an intentional configuration change.

TESTCOMPUTER2 - PIN Failure

AvailableSecurityProperties : 1,2,3,4,5,6,7,8

RequiredSecurityProperties : 1,2,3

SecurityFeaturesEnabled : 0

SecurityServicesConfigured : 1,6

SecurityServicesRunning : 1,2,3,4,6

VirtualizationBasedSecurityStatus : 2

CodeIntegrityPolicyEnforcementStatus : 2

UsermodeCodeIntegrityPolicyEnforcementStatus : 2

TESTCOMPUTER2 - following reboot, PIN working

AvailableSecurityProperties : 1,2,3,4,5,6,7,8

RequiredSecurityProperties : 1,2,3

SecurityFeaturesEnabled : 0

SecurityServicesConfigured : 1,6

SecurityServicesRunning : 1

VirtualizationBasedSecurityStatus : 2

CodeIntegrityPolicyEnforcementStatus : 2

UsermodeCodeIntegrityPolicyEnforcementStatus : 2

The failed TESTCOMPUTER2 boot reported SecurityServicesRunning = 1,2,3,4,6. The corresponding services are:

·         Credential Guard

·         Hypervisor-enforced Code Integrity / Memory Integrity

·         System Guard Secure Launch

·         SMM Firmware Measurement

·         Kernel-mode Hardware-enforced Stack Protection (Audit mode)

By comparison, the subsequent successful PIN boot reported only SecurityServicesRunning = 1, despite retaining SecurityServicesConfigured = 1,6. The configured state did not change, while the runtime state did.

We also disable Memory Integrity and Secure Launch via GPO - so something is enabling them on failed boots.

I'll post another update when I have more information

Hi @Kevin Cooke

Your A/B evidence narrows this well beyond a normal PIN-provisioning problem. The first confirmed failure occurs while Windows is importing the persisted Hello container into the isolated NgcIso environment. Microsoft documents that the Hello container holds the user’s key material and that hardware-backed keys are protected by the TPM.

Given that:

• Multiple users are affected on four units of the same HP model.
• The same users and policies work on a different EliteBook model.
• Reimaging and container recreation don’t prevent recurrence.
• TPM status appears healthy outside the failed boot.
• Persisted container files and the TPM SRK blob remain unchanged between working and failed boots.

the evidence points toward an intermittent platform-specific interaction involving Windows, the TPM/firmware stack, or the isolated Hello container-loading path. This is an inference from the supplied evidence, not a confirmed Microsoft root cause.

There's no verified Microsoft documentation mapping 0xD000A002 from c_NgcIsoContainerImportBuffer, or Events 5701/7002 in this specific sequence, to a documented customer-correctable condition. It also doesn’t match any currently documented Windows Hello for Business deployment issue.

I agree that further container deletion, NGC-folder removal, TPM clearing, or reimaging should be paused on at least one affected device. Those actions recreate or remove the credential state Microsoft would need to examine.

For escalation, provide Microsoft and HP with:

• A working and failed boot trace from the same device.
• The RPC EEINFO and the exact c_NgcIsoContainerImportBuffer failure.
• Events 5701 and 7002 with timestamps and full event XML.
• BIOS, TPM firmware, Windows build, and installed driver versions.
• Persisted-state hashes from the working and failed boots.
• Confirmation that four identical systems reproduce the issue while another EliteBook model doesn’t.
• Whether changing only the BIOS or TPM firmware changes the reproduction rate.

Microsoft confirms that the TPM is used to protect Windows Hello for Business credentials, so opening a parallel HP enterprise case for BIOS/TPM firmware analysis is appropriate.

This appears to require Microsoft product-group and OEM engineering analysis. I don't recommend another generic PIN reset as the primary remediation because you’ve already demonstrated that recreating the container doesn’t prevent the failure.

References:

How Windows Hello for Business works

Windows Hello for Business known deployment issues

TPM recommendations

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.