After several years of “next quarter the implementing act will be signed’, the EUCC implementing act was indeed signed in 2024Q1. As the editing between the last public draft 1.1.1 and the issued implementing act was in secret, the final implementing act actually happening was a bit of a surprise.

Now, in The Netherlands we have prepared the processes to be smooth, so a lot of the potential problems were already solved. We did not communicate these solutions well (as they were “solved” in our minds), and now we are getting questions from the assumptions that there are problems still.

So I thought it would be good to address some of the concerns we’ve heard. As always with these blog entries, these are simplified answers for clarity, not full policy statements with all the exceptions and conditions.

This blog entry was updated on 2024-06-05 to clarify some aspects, most importantly that although NSCIB will stop accepting applications at or before 2025-02-27, NSCIB certificates can be issued still until 2026-02-27. Also clarified that the CCv3.1 recertification is possible for that period under NSCIB, and there is work ongoing to see if CCv3.1 recertifications can be transferred to NL-EUCC.

This blog entry was also updated on 2024-06-25 with the official transition policy document “Transition statement NSCIB – EUCC” published by NSCIB and RDI. It confirms our earlier descriptions, clarifying that certificate maintenance will be possible until 2 years after the certification date.

The best way is to look at the intended/expected certification date:

1. If the certification date is definitely before 2025-02-27, you must use NSCIB (because NL-EUCC cannot issue certificates until 2025-02-27).
2. If the certification date is (likely) after 2025-02-27, you will be pushed to/should use NL-EUCC.
3. There is room for projects to be accepted at NSCIB while the lab (and TrustCB) are not yet fully authorised for NL-EUCC. As it is going now, I predict this likely means before 2024Q4 but at the latest before 2025-02-27. Any such project needs to certify under NSCIB (well) before 2026-02-27. This room is not to be used lightly: we will be holding projects to realistic planning and required progress requirements strictly. Make sure the planning in the evaluation work plan is clear, committed, reasonable, and leads to EM1 well in 2024 and EM3 before 2025Q4.The evaluation meeting dates will be much less flexible than usual due to the scarce capacity at NSCIB requiring strict scheduling. There is a much bigger project risk that if EM dates are missed or extra meetings are needed, the whole project might need to be cancelled as there is very limited room to replan.
4. If the hoped certification date was before 2025-02-27, but it slipped beyond that date while keeping the progress requirements of NSCIB, it needs to complete as soon as possible but definitely before 2026-02-27 when NSCIB will close. We will offer transfer of the NSCIB project to NL-EUCC (similarly as the TRN->TrustCB transition of NSCIB in 2022) in these cases. As we don’t yet know all the steps needed for moving a project NSCIB to NL-EUCC, we can not guarantee this is efficient. If slipping beyond 2026-02-27 is a serious risk, you are better off applying for NL-EUCC as it is easier to go from NL-EUCC to NSCIB than the other way around.

Note that also in NSCIB we expect that projects make significant progress (proceed to the next evaluation meeting) within a month or 4-6, so delays to try to extend the timelines are not advised: you may hit the situation where the project closed from NSCIB side and might not be re-used efficiently.

Background: in The Netherlands there is an intention to implement the EUCC as fast as possible and take the projects on under the RDI as NCCA as fast as possible. This means that applications to the national scheme NSCIB that can also be done to the NL-EUCC, will need to be done under NL-EUCC.

Until 2024-06-30 you can apply for new certifications using CCv3.1 under NSCIB, however they should be completed before 2026-02-27 (note that the above nudged/forced transition to the NL-EUCC scheme applies).

We advise applying in 2024-05 (May) or earlier, as the acceptance date of the application counts as the start of the certification.

After that, only recertifications can be done using CCv3.1 under NSCIB, i.e. based on an existing CCv3.1 NSCIB certificate with essentially the same TOE.  There is work ongoing to see if this can be transferred to NL-EUCC.

Maintenance, and this means certificate maintenance so not (re)certification of any kind, can only be done “until 2 years from the original certification” (and of course only as long as a certificate is valid). Until closure of NSCIB (2026-02-27 at the latest) this should be possible as usual. New as per “Transition statement NSCIB – EUCC”:  as the issuing CB TrustCB can continue with certificate maintenance beyond that, until 2 years after the certificate issuance date.

On or after 2024-07-01 you must apply using CC:2022 both under NSCIB (these will be performed by RDI-personnel) and NL-EUCC.

There has been a lot of noise about CC:2022, but really most of this is because the version identifier looks so much more different (CCv3.1 versus CC:2022).

Changing over from CCv3.1 to CC:2022 requires some rechecking of the ST (and invalidates any CCv3.1 PP certification re-use), but that is it.

Outside the smartcard domain, we don’t see a significant impact. In the smartcard domain, our analysis (a year ago shared with ISCI WG1) showed that the only impactful aspects are:

1. CCv3.1 SFRs from the smartcard PPs that are previously extended component definitions, are now usually included in CC:2022. There is a formal check to do (and a formalized ignoring of the superfluous extended component definition), but this will be a standardized small work unit.
2. SPM is no longer practical (there is some work to make it possible again, but this is still a while out).

The CC:2022 standard has been changed to require full modelling of all SFRs. There is a SOGIS/JIL-WG initiative to define what a reasonable modelling of a reasonable subset of the SFRs of a given PP would look like, with the implied promise that this modelling and subset would be accepted by the various CBs under SOGIS! 

New: the SOGIS/JIL-WG interpretation has been published: “ADV_SPM.1 interpretation for [CC:2022] transition“, listing the scopes for [PP-0084], [PP-0099] and [PP-0101]. For PP-0084 (hardware), the mandatory minimum scope is described as “The MPU/MMU memory management sub-TSF, if this functionality is present in the product, and The code loading sub-TSF, i.e. Loader 1 and/or Loader 2 in [PP-0084] terminology, if this functionality is present in the product.” (My emphasis.)

I hope this helps clarify that indeed these issues are small.

If there are any other questions, please do email us at [email protected].

With kind regards,

Wouter