nRF54L15 Rev.2 Security-Related Errata Clarification (SPU, KMU, DPPI/PPIB, EGU, Reset)

[Mathiyazhagan S]

Hi Nordic Team,

I am evaluating the security architecture of an nRF54L15-based product and reviewing the latest errata for Revision 2.

While reviewing the errata, I found several items that appear security-related

1. SPU Locking (Anomaly #10)
   1. Does anomaly #10 affect the security guarantees of TrustZone isolation in production systems?
   2. If an attacker gains arbitrary code execution in the non-secure application, can this anomaly be leveraged to modify secure/non-secure memory or peripheral attribution?
   3. What is the recommended mitigation when using TF-M and secure services?
2. KMU Provisioning (Anomaly #13)
   1. I am intend to use hardware-protected storage for device credentials, Is there any risk of key corruption or unintended key-slot modification due to this anomaly?
   2. Does NCS/TF-M already implement the recommended workaround?
3. DPPI/PPIB Security Attribution (Anomaly #26)
   1. Can this anomaly result in secure tasks/events being triggered from the non-secure domain?
   2. Are there known TrustZone configurations where this becomes a security concern?
   3. Is this fully handled by existing NCS drivers, or does the application developer need additional precautions?
4. EGU Security Attribution (Anomaly #59)
   1. Can this anomaly lead to unintended interaction between secure and non-secure software partitions?
   2. Are there recommended restrictions on EGU usage in TrustZone-enabled applications?
   3. Does TF-M already account for this limitation?
5. Soft Reset Behavior (Anomaly #63)
   
   1. Are any security-sensitive resources (SPU state, KMU state, secure RAM, peripheral configuration) known to survive a software reset?
   2. Is a full power-on reset required for security-critical recovery procedures?
6. Others:
   1. Are anomalies #10, #13, #26, #59 and #63 expected to be resolved in a future nRF54L15 silicon revision?

   2. Do any of these anomalies impact:

      • PSA Certified evaluations
      • SESIP evaluations
      • Common Criteria evaluations
      • Other security certifications or assurance programs (E.g. EU CRA, etc..)?

I would appreciate any clarification regarding the practical impact of these anomalies on TrustZone isolation, secure key storage, secure boot, secure DFU, and overall platform security.

Thank you for your support.

Best Regards.