<mark>Market implementations: Apple FindMy iPhone, Microsoft InTune, Android screen time for kids through parental controls (or however that works), and Canon FollowMe printing service. The technical definition would even allow VPN controllers such as NordVPN to be evaluated in this context.
</mark>
> Example market implementations: Widely deployed proprietary features from well-known brands such as lost or stolen phone retrieval functions or children’s screen time parental control applications, etc.
## 4.2 Product Architecture
@@ -2597,6 +2596,46 @@ Requirements not covered by Annex R remain addressed by the core part of the sta
**Table Annex R-6: CRA Annex I Part I gap analysis**
# Annex X (informative): Standard development notes
This document is not perfect.
## Notes on 4.1.4 ICT device management
The chapter [4.1.4 ICT device management](#414-ict-device-management) does not have a use-case included.
The following work could be a direction worth exploring:
* The Open Mobile Alliance (OMA) Device Management protocol [OMADM] and LightweightM2M architecture [LWM2M]
* BroadBand Forum (BBF) CPE WAN Management protocol [TR-069] developed extensive specifications to facilitate Device Management over wireless and wireline telecommunication network respectively
* The Globalplatform Remote File Management and Remote Application Management specifications over HTTP [RAMh] and CoAP [RAMc] targeting secure elements such as SIM cards, as well as the Secure Element Management Service for eSIM [SEM] also fall in this category.
References:
* [OMADM] Open Mobile Alliance™: "OMA Device Management Protocol", Version 2.0.
* [LWM2M] Open Mobile Alliance™: "LightweightM2M Architecture", Version 1.0.
* [TR-069] BBF TR-069: "CPE WAN Management Protocol" Issue 1 Amendment 5, November 2013.
* [RAMh] GlobalPlatform Card Specification v2.2 - Amendment B v1.0.1: RAM over HTTP
* [RAMc] GlobalPlatform Card Specification v2.3 – Amendment M v1.0: RAM over CoAP
* [SEM] GlobalPaltform Card Specification v2.3 – Amendment I v1.2: Secure Element Management Service
## Notes on removed section 5.2.5 Software Bill of Materials
Early versions of this document had a section about SBOM requirements.
### The requirements
These requirements are generally binding, and there is no low-medium-high tiering available.
-**[REQ-SBOM-0]:** Operating system dependencies and application dependencies shall be clearly separated in the provided SBOM.
-**[REQ-SBOM-1a]:** Unique, unambiguous, and machine-readable identification of all components and dependencies shall be provided in the SBOM.
-**[REQ-SBOM-1b]:** The SBOM identifier format shall be consistent with common vulnerability handling standards.
-**[REQ-SBOM-2]:** The SBOM shall be consistent with [5.3.4 Secure updates] practices.
### Removal reason
There are no clear instructions or interfaces available.
The SBOM format and generation is not a concern that is unique for the products in this category.
