Replies: 1 comment 2 replies
-
The product definitions will be further defined in an Implementing Act with consultation (see Art. 7.4). For the manufacturer the only thing that matters in terms of that classification is the PDE that is put on the market, not the PDEs that that product consists of. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Annex II lists two classes of "Important Products with Digital Elements": Class I and Class II. The granularity varies enormously, from microprocessors with security-related functionalities to personal wearable products.
In some cases, it might be expected that a PDE which incorporates another PDE from a particular class would also expect to be classified at the same level: e.g. an document-signing product which used a PKI (class I, 9.) is likely to be class I as well. However, there are cases where this seems to make no sense. There is a need for clarity in the industry.
Case 1
Hypervisors and container management systems are class II PDEs (class II, 1.). It makes no sense (hopefully!) for any application that uses virtualisation to be considered class II.
Case 2
Microprocessors with security-related functionalities are class I PDEs (class I, 13.). Many server-grade CPUs and GPUs now contain security-related functionality - for instance Trusted Execution Environments. If a PDE does not use a TEE, the hope would be that it wouldn't be promoted to class I.
Case 3
As with case 2, but if a PDE makes use of this functionality, it probably should be classified as class I.
Case 4
There are capabilities of microprocessors which a security-related but which probably shouldn't automatically classify a product as class I just because they're used: e.g. AES hardware-offload, hRNG (hardware random number generators).
Beta Was this translation helpful? Give feedback.
All reactions