Detect & Response set of requirements missing about iot-security-verification-standard-isvs HOT 1 OPEN

DnR operations should be out of scope IMO. Widening the scope to include processes and operational procedures that vary based on the organization typically have reliance on compliance program requirements but also internal mandates based on incidents. Perhaps im missing the intention. Feel to clarify :)

root keys cannot be remotely updated.

A best practice is to design with cryptographic agility including a plan that incorporates root key compromise and rotation of those. IoT platforms can provide this capability to remotely update key sets when incidents occur or as part of a rotation policy through OTA.
Lorawan docs mention how this might be performed with a key management system and a "secure" Arm MCU reference architecture though im not sure if this has been deployed in practice. See the following:
https://lora-alliance.org/wp-content/uploads/2020/11/cypress-escrypt-member-security-whitepaper_web-opt.pdf

Side note: We should add the following Lorawan security FAQ reference: https://resources.lora-alliance.org/faq/lorawan-security-faq

Re: 4.5.8
MAC addresses are generally trustworthy. How reliable are MAC address comparisons as a means to validate legitimacy if they can be changed through software means?

from iot-security-verification-standard-isvs.