[Magisk] zgfg:
Strong Integrity means that CTS had to be attested by the hardware-backed TEE = Trusted Execution Environment (hence not by the 'regular' software where you can spoof things) and its attest signed by the TEE's private key

But you cannot spoof TEE - if you succeed on eg the new Pixels with Titan, you will be eligible for 0,5 - 1 M $ reward (bounty) from Google

It was all discussed in details in tens of posts here on XDA, in various threads, pointing to the official Google documentation how Play Integrity API and TEE work

Eg, USNF does two things. First it spoofs the phone model so that Google Play Services and its PI API thinks that you have an old phone with no (or not reliable) TEE.

Therefore, instead of on the TEE, CTS gets attested by the 'regular' software, reading the other spoofed props, etc and hence returning the spoofed CTS pass.

But it was not attested and signed by TEE, hence that Basic CTS attest is valid only for Device Integrity but not for the Strong Integrity pass (requiring the Hardware based CTS attestation on TEE)

If the CTS would be really tested on TEE, then TEE would not mind for the props spoofed by USNF and it would immediately recognize that eg Bootloader was unlocked, that ROM is no more the certified stock, etc - hence CTS attestation on TEE would fail and you would not pass the Play Integrity API at all

That's the reason why USNF forces the software or Basic CTS attestation (that is not valid for the Strong Integrity)

However, the good thing is that apps still don't require Strong Integrity yet (ie, allowing Device Integrity attested by the software instead), since they know that there are still plenty of old phones around without the (proper) TEE's, hence not applicable for the Hardware backed CTS attest, ie for the Strong Integrity

However, it is really strange that Google does not enforce just a little bit smarter mechanism where PI API would nevertheless try to enforce attestation on TEE, where TEE would then easily find what is your real phone model and is it applicable for the CTS attestation on the TEE or not - then the USNF (and your Riru modules, whatever you want) would no more be able to spoof the TEE to obtain the spoofed CTS attest and thus the spoofed Play Integrity pass

Btw, make your PI API or the old S/N attest, then click to Open JSON response and you will find the Basic CTS attest (on your 'rooted' phone with all the spoofs required).

Only if you go back to stock and relocked Bootloader, you will see the Hardware backed CTS attest and the Strong Integrity pass

PS: I see you are referring to the SafetyNet, not Play Integrity.

They are actually similar and both include the CTS attestation (either by software or on TEE, hence for both the same comments about TEE apply)

However, S/N is deprecated by Google. Since the last summer Google Play Services include both APIs but Google will soon drop the S/N and all apps on Google Play (who want to call attestation) will have to switch to the PI API instead - most already did

And PI (or deprecated S/N) is only a part of the 'root detection' game for most 'banking' apps. They all know its weaknesses (possibility to spoof the Google's CTS by switching to attestation by software) and therefore they additionally use other detection or guessing methods for whom you need your mentioned Riru modules, etc

But those hidings by Riru modules (Privacy, etc) or HMA are not related to the S/N or PI. For S/N or PI you just need USNF (modded), the rest you need for your apps because they see that you pass PI (S/N) but they are still not convinced that your phone is not 'rooted' and they want to dig deeper - welcome to the mice and cat game