If SCCM imaging keeps failing on TPM 2.0 devices and the machine enters a reboot loop, the TPM is often not the only problem. In many cases, the real cause is a bad task sequence flow, a BitLocker step firing at the wrong time, a boot image issue, or firmware and UEFI settings that do not match the deployment design. Microsoft’s current guidance supports all of those failure paths.
This guide shows the fastest way to diagnose the loop, isolate whether BitLocker is the trigger, and fix the task sequence without guessing. It starts with the safest checks first, then moves into the stronger fixes if the problem stays.
Quick Answer
If SCCM imaging fails with a TPM 2.0 boot loop, first confirm the device is in UEFI mode with TPM 2.0 enabled and activated. Then update and redistribute the boot image, test the task sequence without Pre-provision BitLocker, review smsts.log, and if you use a Windows 11 boot image, add the Microsoft workaround that sets OSManagedAuthLevel=2 before the Pre-provision BitLocker step.
What Does a TPM 2.0 Boot Loop During SCCM Imaging Mean?
This problem usually indicates that the deployment reaches a point where the device cannot complete startup, encryption, or TPM initialization correctly. The loop often shows up during or after BitLocker steps, after the first reboot into the full OS, or after boot image and ADK changes.
On modern hardware, the failure is often tied to one of these areas:
- Pre-provision BitLocker in WinPE
- Enable BitLocker in the Full OS
- TPM 2.0 Not Enabled or Activated
- UEFI or Secure Boot Mismatch
- Boot Image Drift After ADK Changes
- BIOS or TPM Firmware Problems
Why Does SCCM Imaging Fail with TPM 2.0?
The failure usually happens because the task sequence expects the TPM, boot image, and BitLocker flow to be in a ready state, but one part is not. Microsoft documents that Pre-provision BitLocker requires a supported and enabled TPM in Windows PE, and that Enable BitLocker in the full OS needs the TPM enabled, activated, and ownership allowed. The Check Readiness step can also verify UEFI mode and TPM 2.0 status on newer ConfigMgr versions.
Main causes include:
- TPM 2.0 Not Enabled in BIOS
- TPM 2.0 Not Activated
- Device Not Running in UEFI Mode
- Secure Boot or Firmware State Mismatch
- Pre-provision BitLocker Failing in WinPE
- Boot Image Not Rebuilt After ADK or ConfigMgr Changes
- Model-Specific BIOS or TPM Firmware Issue
- Task Sequence Ordering Problem
How to Fix SCCM Imaging TPM 2.0 Boot Loop
Follow the fixes below one by one. Start with the simplest checks first, then move into BitLocker and boot image changes only if needed.
1. Verify UEFI, Secure Boot, and TPM 2.0 State
This is the first place to check. A task sequence can fail fast if the device is not configured the way BitLocker and modern OSD expect. Microsoft’s Check Readiness step can validate whether the device is in UEFI mode and whether TPM 2.0 is enabled and activated.
Check these items:
- UEFI Mode Is Enabled
- Secure Boot Is Enabled if Your Design Requires It
- TPM 2.0 Is Present
- TPM 2.0 Is Enabled
- TPM 2.0 Is Activated
If one of those is wrong, fix it in BIOS first and test imaging again.
2. Add or Review the Check Readiness Step
Many task sequences fail too late because they do not test the platform early enough. Microsoft supports readiness checks for UEFI mode, TPM 2.0 enabled, and TPM 2.0 activated in Configuration Manager.
That makes this a strong preventive fix. Instead of letting the device reach BitLocker and fail, stop the deployment early when the firmware state is wrong.
3. Rebuild and Redistribute the Boot Image
If the problem started after an ADK upgrade, WinPE change, or ConfigMgr update, the boot image may be out of sync. This is a common cause of strange OSD failures around TPM and BitLocker behavior. Microsoft support guidance around these cases regularly points admins back to boot image and ADK alignment.
Do this next:
- Update the Boot Image
- Refresh Optional Components if Needed
- Redistribute the Boot Image to Distribution Points
- Retest the Task Sequence on the Same Hardware
4. Test the Task Sequence Without Pre-provision BitLocker
This is one of the fastest ways to isolate the trigger. Microsoft documents that Pre-provision BitLocker runs only in Windows PE and requires a supported and enabled TPM. If removing or disabling that step makes the loop disappear, you know the issue is in the early BitLocker workflow and not in the whole task sequence.
You do not need to remove BitLocker forever. Use this as a clean test first.
5. Apply the Windows 11 Pre-provision BitLocker Workaround
This is one of the most important fixes for this topic. Microsoft support guidance documents a known issue where Pre-provision BitLocker can fail with Windows 11 based boot images unless you set the TPM policy value OSManagedAuthLevel=2 before the step.
Add a Run Command Line step before Pre-provision BitLocker and set the required registry value. This is the exact kind of fix that many generic SCCM articles miss, even though it directly targets the loop pattern on newer TPM 2.0 devices.
6. Review the Enable BitLocker Step
Do not focus only on Pre-provision BitLocker. The full OS Enable BitLocker step can also trigger problems if the TPM is not in the correct state. Microsoft says the TPM must be enabled, activated, and ownership allowed before the step can run properly. The step can also complete the remaining TPM initialization in the full OS.
That means a reboot loop after the OS phase may still be a BitLocker and TPM timing problem, not just a BIOS issue.
7. Check smsts.log for TPM and BitLocker Failures
Do not guess when the log can tell you where the task sequence broke. If the loop happens during imaging, smsts.log is one of the best places to confirm whether the failure happened at Pre-provision BitLocker, Enable BitLocker, or another reboot-related step. Microsoft task sequence guidance and common support patterns both point to this log as a key diagnostic source.
Look for clues such as:
- Failure at Pre-provision BitLocker
- TPM Ownership Errors
- BitLocker Step Return Codes
- Reboot Requests at the Wrong Time
- Errors Around OSDOfflineBitLocker.exe
8. Update BIOS and TPM Firmware on the Affected Model
If the issue happens only on one hardware model, firmware becomes much more likely. Microsoft’s BitLocker and TPM guidance explains that TPM and firmware changes can affect startup behavior, including recovery and reboot problems. It also notes that TPM 2.0 with PCR 7 handles firmware measurement better than older TPM 1.2 patterns, which is another reason newer platform behavior can feel different during deployment.
Check for:
- BIOS Updates
- TPM Firmware Updates
- OEM Notes About Windows 11 or BitLocker
- Changes to Secure Boot Defaults
9. Compare a Working Model Against the Failing One
This step saves time in larger environments. If one model images correctly and another loops, compare them side by side.
Focus on:
- BIOS Version
- TPM Firmware Version
- UEFI and Secure Boot State
- Storage Controller Mode
- Same Boot Image Version
- Same Task Sequence Version
That comparison often shows whether you have a platform issue or a task sequence issue.
10. Move BitLocker Later if Needed
Sometimes the best fix is not to force encryption earlier. If the loop disappears when you delay BitLocker until the full OS is stable, the task sequence may simply be trying to do too much too soon.
Microsoft’s own step design already splits Pre-provision BitLocker in WinPE from Enable BitLocker in the full OS. If early encryption is unstable on a model, moving the protection flow later can be the safer design.
11. Watch for BitLocker Recovery Style Loops After Imaging
Some devices complete imaging but then loop into BitLocker recovery or repeated reboot behavior. Microsoft documents that firmware or TPM changes can trigger recovery if the protector measurements no longer match expected values. On modern devices, PCR 7 and Secure Boot state matter here.
If that is your pattern, check:
- Recent BIOS or TPM Firmware Change
- Secure Boot State
- PCR Binding Behavior
- Whether BitLocker Was Enabled Too Early
How to Prevent SCCM TPM 2.0 Boot Loops in Future Deployments
These habits reduce the chance of seeing the same issue again.
- Use Check Readiness for UEFI and TPM 2.0
- Rebuild Boot Images After ADK Changes
- Test Pre-provision BitLocker on New Hardware Models
- Keep BIOS and TPM Firmware Current
- Review BitLocker Step Order Carefully
- Validate on One Pilot Device Before Wide Rollout
- Keep smsts.log Collection in Your Standard Troubleshooting Flow
Final Thoughts
SCCM imaging failures with TPM 2.0 boot loops are usually not random. In most cases, the issue comes from one of four areas: TPM readiness, BitLocker timing, boot image drift, or firmware state. Start by checking UEFI and TPM 2.0, then isolate Pre-provision BitLocker, review smsts.log, and apply the Windows 11 workaround if it fits your environment.
If you want the fastest path, test the same device once without Pre-provision BitLocker. That single change often tells you whether you are dealing with a TPM platform problem or a task sequence design problem.
