Trezor devices run a feature-fit firmware that implements its underlying system, and it’s called Trezor Core.
Trezor Core seems to not utilize any sort of hardware acceleration, relying on software-based approach. Libraries located on the Trezor monorepo have implementations of common cryptographic formulas and also own implementation of bignum [https://github.com/trezor/trezor-crypto/blob/master/bignum.c]. This is also further proven by the fact, that hardware used by both Trezor devices doesn’t have any sort of hardware acceleration aside from CRC calculation. The implementations of said algorithms don’t have any added side-channel attack mitigation, for example to prevent sniffing of date via power consumption readouts, as was done previously with Trezor One OLED display’s power consumption Details of the OLED Vulnerability and its Mitigation | by SatoshiLabs | Trezor Blog and CVE - CVE-2019-14353 (mitre.org). As far as it’s known, Trezor Model T doesn’t have this issue kind of issue so far.
The device also lacks an SE, which is a notable security concern if the SOC itself isn’t secure enough or isn’t build to sustain specific and/or advanced attacks to the hardware. This have had been exploited via RDP Downgrade vulnerability discovered by Kraken Labs Kraken Identifies Critical Flaw in Trezor Hardware Wallets - Kraken Blog. Which allows the adversary to extract contents of the SOC’s flash memory, allowing them to reliably break into the device while circumventing the wipe mechanism, which occurs on 16 unsuccessful tries. This exploit can be mitigated by setting a Passphrase which is not stored in the flash memory and not losing the device or letting the device unattended for an extended period of time.
Both solutions unfortunately don’t solve this hardware flaw, and it cannot be fixed by a firmware patch. Trezor released a statement on their blog that says, that the regardless how secure the software can be, the physical attacks will happen, but they don’t know when they’ll happen. So their primary focus upon all was to make the software as secure as possible to prevent attacks without necessary attendance to the hardware. Our response to the read protection downgrade attack
In the same article they’ve also stated, that their focus was on picking the most transparent hardware, releasing everything as freely as legally possible. Not only for building trust to the device by being transparent but also to make its security publicly scrutinizable.