Nitrokey3 - physical security

The Nitrokey 3 supports both OpenPGP (using a secure element soon) as well as Fido2.
With a secure element, I understand that PGP/SSH keys will be protected from physical attacks as well as software extraction.

But I have not found anything about the physical security of Fido2 keys (authentication keys as well as the HMAC-secret extension) and Pin stored on the device.

The question is: What if an attacker gets physical access to a Nitrokey 3 and disassembles it to gain access to the MCU? Is it possible to extract either the Fido2 material or access Pin or is this also protected similar to a secure element?

The Nitrokey uses a framework called Trussed. This offers highlevel key store functions to deal with storing secret material. A backend is then defined and can be different depending on the used hardware.

As I understand it, the Secure Element is the dedicated chip NXP JCOP 4 SE050M.

However the backend could also be the ARM Trust Zone in the LPC55S6x / nRF52 or software based Encryption-at-Rest using a device key protected/derived by the User PIN.

Features that are in testing stage might use software based backend so that the feature works across Nitrokey 3 with different hardware (due to chip shortage a different processor was sourced). That way testing would be easier. For released features, this can then be configured to use the dedicated Secure Element.

PINs are not stored but only cryptographic hashes.

PINs are not stored but only cryptographic hashes.

The question is, if it is at all possible to extract this hash (or any other secret material) if an attacker gains physical access to the chip.

We know from this thread

that SE050 is not used in the Trussed-based firmware released as of April 2023.

I think the question is about physical security of the data on the chip itself. Only in the case we could demonstrate that the firmware uses certain features preventing certain physical attack(s), like using some kind of more protected element than the main CPU on the token itself to store sensitive data, we can disregard physical security properties of the chip.

In other words, suppose the main CPU on the token is compromised, does that mean that the data we have entrusted in the device are compromised, too?

The question has been answered to some extend in the comments here: