We are still debugging this with AMD/MSFT. However I ran into an issue that you might be able to help with me.
I was previously using a trial of Intune+Entra P2. But our trial expired. I migrated to Office 365 Business pro license which also includes Intune+Entra P1. From what I can find regarding licensing, this should have the same features we need to test.
However now I get a new error, that I was not seeing before: Do any of you think this could be related to licensing?
hi @Kieran_Levin, thats not related to the license.
Thats one of the issues we are facing here in the topic.
Same erros in Intune in my environment (E5 License)
@Kieran_Levin - I also have the same issue and just sent in my logfiles via ticket named “Submission from Service Request Form: Cannot get FW13 Compliant in InTune - known Pluto issue?”
I am happy to support, please DM me any time.
(Also happy to provide you guys a fully licensed E5 testuser if that helps).
Andreas
So I just had a call with an Intune Support Engineer. He will further analysed but shared the following with me:
The more I think about it, the more critical it gets.
Basically, like it is now, this chipset cannot be used for Business use if Intune should be used - this is something which Framework should clearly put on their website until the issue is fixed.
Also, I would kindly ask the Framework team to come up with a timeline if/when this is going to be fixed. We have several devices we would like to order but obviously won’t until we know this is fixed. If it cannot be fixed without replacing the hardware, this is a different discussion but knowing would help, because customers then either decide to go Intel or buy a different platform.
Andreas
After further debugging with both AMD and Microsoft, Microsoft has confirmed the issue is on the Windows end and they have escalated it internally to the relevant team. This means we don’t currently expect that any BIOS update will be needed to resolve Intune support. We don’t yet have feedback from Microsoft on the schedule on their end.
Is there any news on this? As we have already commented on this thread this issue makes the AMD version of the Framework 13 (and the 16?) unusable in a business environment. At the very least it needs to be made very clear on the “Framework for Business” website that the AMD variant will not be functional if the customer employs Intune Compliance Policies for Encryption
Another user strobert linked me to this thread as we’re having similar issues with our own new AMD units:
AMD 13 & 16 - SecureBoot, CodeIntegrity & BitLocker erroneous reporting - Community Support - Framework Community
I’ve kicked off cases with our own MS contacts - will post to here if I unearth anything of substance.
We are still working with MSFT to get this resolved, but we do not have a resolution yet.
One thing that would be helpful for us at this point is to consolidate the different Microsoft case numbers.
If you are willing to do so, it would be helpful for us to get the case numbers through support. And mention in your subject:
Intune autopilot issue: Casenumber.
And mention to escalate this to Kieran.
Thanks!
Done!
Just noting two items here from trying to debug this:
Windows has an optional feature that you can install called tpmdiagnostics.exe
Which has some commands for attestation debug.
There is also a more advanced utility as part of the HLK, tpmutil.exe which has some more options, but some options look unsafe to use with attestation, (it looks like you can clear/reset/load attestation).
Switching from the Pluton TPM to the PSP firmware TPM is not something we want to enable at the moment, as it cannot be done seamlessly during the BIOS update process. We are going to track this with Microsoft.
is tpmutil.exe in reference to that earlier, if yes where do I find it, if not, how is that coming along so far? (I’d really prefer not using pluton)
@Kieran_Levin - cross posting from my other thread for visibility. I’ll message separately with case ref.
After some back and forth with our MS contacts and some support/diagnostic sessions - current opinion is that InTune IS in fact reading in the device status correctly, the fault is within InTune’s own reporting functions.
Latest I have right now is, and I quote:
“This is a Reporting issue from InTune end, this should be fixed by next InTune release.”
What I don’t have yet (I’m pressing for it) is a confirmation of that from the InTune engineering team, or visbility of it in the InTune development board.
Will update again as and when I get more.
Has anyone heard of a status update on this?
Only thing I’ve got at the moment is MS being adamant that the change in attestation reporting that’s coming in InTune 2405 will resolve the issue.
I’ve nothing of substance beyond that, and was holding off posting until I had some proof one way or the other.
Doesn’t look like it solves the issue (?) on 2405 
. Did a PC reset, reinstalled the driver pack, waited for Bitlocker to finish, etc.
Can confirm - we got it earlier this week, all AMD units still reporting failures.
I don’t actually have a Framework Laptop (I like the concept though and will be looking very closely next time I’m in need). However I am experiencing the same issue as reported here and this seems like a productive thread that I want to follow for the eventual fix (hopefully).
Getting this issue on a new Framework 16 which is a blocker for using this as a work machine so following this thread
I have this issue as well. My situation is as follows:
We have three Framework 13 (1x Intel, 2x AMD) and one Framework 16 (AMD) at work.
The Intel and one AMD device (13") currently run Windows 11 from an internal SSD and are domain-joined with Bitlocker and everything working as intended.
The second 13" AMD device (AMD Ryzen 7 7840U) is currently used as a test and utility device. The internal SSD has no OS on it. I did a Windows-To-Go installation on a 1TB storage module and got it domain-joined with working Bitlocker as well. No problems so far.
Recently I received the new 16" Model (AMD Ryzen 9 7940HS). I put Windows 11 (23H2) on another 1TB storage module and tried to set it up just like the 13" model. I got it AD-joined, but Windows didn’t enable Bitlocker by itself or asked to set a PIN. When trying to manually enable Bitlocker, I was always asked for a password because Windows apparently didn’t want to use the TPM. That’s where this whole thing began.
I did some research and spent a lot of time for trial and error with this, but haven’t gotten any further for now. I want to share my observations with you so that we maybe can fix this together. When I refer to the ‘13" device’, I mean the 13" AMD device with Win11 on a storage module and Bitlocker working. With ‘13" module’ I mean the module that is “natively” working in there and coupled to the TPM. So this is the current status:
So yeah, I already spent a lot of time on this and my current conclusion is, that either Microsoft or Framework (or both) should get this fixed soon. I wonder why people have problems with the 13" AMD Laptop though. That one is working like a charm for me.
