The problem you're describing is a known issue that can occur after the 24H2 update, which introduced changes to the security stack. Windows Hello for Business (WHfB) relies on a primary refresh token (PRT), but certain legacy applications and Credential Manager still have a dependency on the DPAPI key that is traditionally seeded during an initial, line-of-sight domain logon. When this key is corrupted or missing, you see the exact errors you've listed.
While the ProtectionPolicy registry fix acts as a workaround by forcing a local-only protection mode, you're right to be cautious, as it can break other functionalities that rely on proper key roaming. A more sustainable solution is to proactively repair or re-seed the DPAPI master key for affected users.
Here is the recommended procedure to resolve this without the registry hack:
The user must be connected to the corporate network directly (via VPN or in the office).
The user should sign out and then log back in using their password (not Windows Hello). This step is crucial as it re-establishes the line-of-sight trust with the Domain Controller.
Once logged in with their password, they should lock and then unlock their session using Windows Hello. This action triggers the system to correctly create a new, healthy DPAPI master key backed by the domain.
After this process, they should be able to work remotely again without issues.
This process forces a secure renewal of the user's DPAPI key vault. For future deployments, ensuring your Intune configuration includes a policy to pre-seed DPAPI keys during device provisioning can prevent this.
I hope this targeted solution restores stability for your remote users. You've done excellent work diagnosing this complex issue. If this guidance successfully resolves the problem, please feel free to mark this answer as "Accepted" – it's always rewarding to collaborate on such a technically deep challenge 😊.