[Magisk] pndwal:
No, not by Google... It's an opt-in choice for banks etc...

Google have simply provided for strengthened keystore implementation requirements with each API/SDK level as well as the device integrity APIs that allow app Devs to poll 'strong' (hardware backed) attestations if they wish.

You'll find a lot on this in my old posts, but neither have Google nor banks enforced S/N ctsProfileMatch with HARDWARE evaluationType or its very similar big brother, PI strongIntegrity, in their own apps and in the case of banks, It's NOT that they don't want to use such strong S/N / PI attestations; they certainly do!

Really the reason is that what G has handed banks is a big white elephant!... It's hard to get a white elephant to work for you.

Nb. The following is also the reason Banks have persued custom root/modified runtime environment detection:

It's not that PI strongIntegrity won't do the job effectively, it's just that this elephant will trample too many customers to death if it's put to work...

Google have actually given us (the modding community) a more real gift (of time at least) by providing banks with the strong attestation system they demanded, but engineering this in such a way that it must be used for all devices or none... Because, as noted above, not all Android devices meet the Android specs for strong attestations (in the case of Droidguard attestations used by S/N and PI APIs the min spec is keymaster 3, introduced with Android 8, properly implemented by OEMs), as soon strongIntegrity is introduced banks will ensure that all users with devices launched with Android 7 and below (even if running late Android) as well as countless users of modern devices who's OEMs have only recently fixed noncompliant keymaster and other AVB chain of trust issues, most notably OnePlus, become casualties; These users will need to purchase new(er) devices before they can use the bank's apps, and many would, of course, rather vote with their feet...

To date, this simply represents too much collateral damage among customers, and so banks have sighed and put the white elephant in storage... 🤪

So the cat/mouse game stays interesting... Banks ahead with Zygisk detection etc ATM, but upcoming native bridge loaded Zygisk seems likely to change that particular game any tick of the clock! (Shana's been on it since beginning of March and to do list indicates it's almost mature enough to merge.)

Quietly, I can't understand why the Bs are still messing with these methods, paying companies like Promon for security (detection engines etc) with the "documented method for Hardware Key Attestation" @V0latyle linked above on the table... This can simply attest to locked and verified (Nb. locked and self-signed is an AVB issue, not 'verified' execution environment) bootloader on any device unlike S/N or PI (read 'no-one with un-modded devices gets trampled by this mammoth') while ensuring (strong) hardware key based attestation is used on all devices with proper support, but aside from official Google and vvb2660/Rikka (Magisk/LSPosed Devs) POCs (and vv's is already being improved to more properly replicate the tamper-proof nature of implementations using server end verification of key signatures and decryption of extension data etc), nada! 🙃 Ah well, suits us!

... Bit like watching a big beautiful bubble bobbing along the beach in the breeze really.

...and thanks anyway for the brief hiatus (/distraction?) Google...

Might wake up any time... Or not... 😋 PW