EN 18031 CRY-1: How to Demonstrate Best Practice Cryptography

[CRY-1] Best practice cryptography is the single requirement in the CRY section of EN 18031. Its wording is short: "The equipment shall use best practice for cryptography that is used for the protection of the security assets or network assets", with one exception for cryptography whose deviation is justified under another section. The difficulty is not choosing AES-256 over DES. The difficulty is proving, in your technical documentation, that every cryptographic choice is best practice, with a citable source behind it.

The requirement text in EN 18031-1:2024, clause 6.11.1 is deliberately compact:

"The equipment shall use best practice for cryptography that is used for the protection of the security assets or network assets, except for: cryptography used for a specific security mechanism, where a deviation is identified and justified under the terms of sections ACM or AUM or SCM or SUM or SSM."

Two things follow from that sentence. First, the scope is tied to your assets: CRY-1 applies to cryptography that protects security assets or network assets (and, in EN 18031-2 and EN 18031-3, privacy and financial assets). If you have not identified your assets properly, you cannot scope CRY-1 correctly. Second, there is an escape hatch: cryptography whose weakness is already identified and justified under ACM, AUM, SCM, SUM or SSM is out of scope here, because the justification lives in that other section.

EN 18031 assesses each requirement through a decision tree. CRY-1 has exactly two decision nodes, applied to each cryptographic mechanism protecting an in-scope asset:

The verdict rules matter as much as the tree. A PASS requires at least one path ending in pass, no path ending in fail, and correct justifications throughout. A missing or incorrect justification produces a FAIL even when the underlying cryptography is perfectly sound. In other words, you can fail CRY-1 with good cryptography and bad paperwork.

CRY-1 also carries a functional completeness check (is there cryptography on the device that you never documented?) and a functional sufficiency check (does the implementation match what you documented?). Changes introduced by security software updates are explicitly not counted as deviations.

EN 18031 does not define a formal taxonomy of acceptable evidence. What it does provide, in the Guidance and notes to clause 6.11.1, are three recognisable routes. Reading them as three options is a practical interpretation rather than a literal clause structure, and it is worth stating it that way in your documentation.

The standard's Guidance points to "publicly available crypto catalogues provided by SDOs and public authorities", naming sogis.eu and the SOGIS Agreed Cryptographic Mechanisms, ETSI TS 119 312, guidance from ENISA, the NIST SP 800 series and BSI TR-02102-1. This is the cleanest route: the mechanism, key length and mode you use appear as recommended in a named catalogue, and you cite the document, version and date.

The Guidance states that "a commonly used cryptographic method for a certain use case, with the lack of evidence for a feasible attack with current readily available techniques, can be considered as best practice." This route is useful for mechanisms that are widely deployed but not itemised in a catalogue. It is weaker than a catalogue citation, and it obliges you to keep watching: today's absence of a feasible attack is not a permanent property.

The standard explicitly allows new cryptography: "it is also possible to provide evidence, that new cryptography is suitable for a certain use case and can therefore be considered as best practice for cryptography." In practice this means published cryptanalysis, peer-reviewed security proofs and independent evaluation. Expect this route to attract the most scrutiny in an assessment.

One caution about a claim you will see elsewhere: using a certified implementation (for example a FIPS 140-3 validated module) is not presented by EN 18031 as an evidence route in its own right. The nearest statement is a preference, that reviewed or evaluated implementations "may be preferable used". A validated module is excellent supporting evidence for correct implementation, but the argument that your algorithm choice is best practice still needs a catalogue or an analysis behind it.

This is where a lot of EN 18031 documentation is quietly out of date. EN 18031-1:2024 names sogis.eu in its Guidance, and most articles on this topic still tell you to cite the SOG-IS Agreed Cryptographic Mechanisms. That advice has expired.

The SOG-IS website now carries an unambiguous notice: "As of 27th February 2026 SOG-IS cease to emit certificates, this website is no longer updated". The last published SOG-IS catalogue is version 1.3 from February 2023. Confusingly, the supporting-documents page still says the document will be regularly updated, which is stale text contradicted by the cessation notice on the homepage.

The successor is the ECCG Agreed Cryptographic Mechanisms, maintained by the ECCG subgroup on cryptography under the EUCC scheme established by Commission Implementing Regulation (EU) 2024/482 and published through ENISA. The operative version is v2, published 6 May 2025, and a version 3 draft went to public review on 2 June 2026. ACM v2 is also the first official EU recommended list to include post-quantum algorithms.

None of this makes EN 18031 wrong. The standard names sogis.eu as an example of the kind of catalogue to use, and its guidance is generic by design. What changes is which document you should actually cite in your CRY-1 justification today.

A practical note on keylength.com: it is a handy aggregator, but its newest source data is from 2020, before the post-quantum standards and before six annual BSI revisions. Its copyright line auto-renders the current year, which makes it look fresher than it is. It is not the kind of source that satisfies a CRY-1 evidence requirement on its own.

CRY-1 is not an isolated box to tick. Cryptographic evidence propagates through EN 18031, and the dependency is stronger in some places than others. It is worth knowing which is which, because only two requirements make best practice cryptography a normative shall.

CCK stands for confidential cryptographic key. The 112 bit minimum security strength in CCK-1 is one of the few concrete numbers in this part of the standard, and it is a useful sanity check across your whole key inventory.

A common error in guidance on this topic is to list AUM-6 (brute force protection) as cryptography-dependent. AUM-6 requires authentication mechanisms to be "resilient against brute force attacks"; cryptography appears only as one example technique in its guidance, not as a normative requirement. Including it in a list of hard CRY-1 dependencies overstates the link.

Five sections can grant a justified deviation from best practice cryptography: ACM, AUM, SCM, SUM and SSM. The same escape hatch appears in CRY-1, CCK-1 and CCK-2. This exists for real engineering constraints, most often interoperability with a protocol you do not control. Using it is legitimate; using it without writing down the justification is how CRY-1 turns into a FAIL.

EN 18031 contains two distinct rules about time, and they are frequently merged into one. Keeping them apart will make your documentation clearer and your assessment smoother.

The Guidance acknowledges that "cryptographic protection might not be compliant with best practice cryptography if interoperability is required", and that legacy mechanisms deployed at large scale are considered to provide acceptable short term security while suffering security assurance limitations compared with catalogue best practice. It then notes that crypto catalogues list legacy mechanisms with a validity period given by a deprecation deadline, and are updated on a short-term basis, typically annually.

Separately, the standard warns that for equipment that cannot have its cryptographic algorithms or primitives updated, for example where a hardware-based root of trust is used, "it is important that the intended lifetime of the equipment does not exceed the recommended usage lifetime of the cryptographic algorithms and primitives used by the equipment." This is a design constraint on non-updatable devices, not a statement about legacy interoperability. The rationale reinforces it: cryptography is more likely to become unsuitable when there is already evidence it may be deprecated within the equipment's intended lifetime.

This is where CRY-1 stops being a paperwork exercise. NIST finalised its first post-quantum standards on 13 August 2024: FIPS 203 (ML-KEM, key encapsulation), FIPS 204 (ML-DSA, signatures) and FIPS 205 (SLH-DSA, hash-based signatures). Europe followed with a coordinated plan.

Put those dates next to a radio device certified in 2026 with a ten year service life and the implication is direct: your CRY-1 evidence should state not only that your cryptography is best practice today, but that the equipment can be updated when the catalogues move, or that its intended lifetime ends before your algorithms do. That is exactly what Rule 2 above asks.

This is the practical meaning of crypto agility in an EN 18031 context, and it is far more useful in your technical file than a bare statement that you use AES-256.

Working through this list will produce a CRY-1 entry that survives scrutiny:

No. EN 18031 deliberately avoids publishing an algorithm list, because such a list would age faster than the standard. It defines the obligation (use best practice cryptography) and points to external catalogues that are maintained on an annual cycle. Your job is to make and cite the choice.

It helps but does not by itself answer the question. A validated module is strong evidence that the implementation is correct and tested. CRY-1 asks whether the cryptography is best practice for your protection goal, which is a question about algorithm, key length, mode and use case. Pair the certificate with a catalogue citation.

Only as a historical reference. SOG-IS ceased issuing certificates on 27 February 2026 and its website is no longer updated, with the catalogue frozen at v1.3 from February 2023. Cite the ECCG Agreed Cryptographic Mechanisms, or BSI TR-02102-1, or the relevant NIST SP 800 publication instead.

That is anticipated. Identify the deviation and justify it under the relevant section (ACM, AUM, SCM, SUM or SSM). CRY-1 then evaluates as not applicable for that mechanism via decision node DN-1. What is not acceptable is an undocumented deviation.

Not today. No current EN 18031 requirement mandates post-quantum algorithms. But the EU roadmap targets the end of 2030 for high risk use cases and BSI ends stand-alone classical key agreement recommendations after 2031, so for equipment with a long service life the honest answer in your documentation is a statement about update capability, not silence.

All three. CRY-1 appears in EN 18031-1, EN 18031-2 and EN 18031-3, with the asset scope widening from security and network assets to privacy assets (part 2) and financial assets (part 3).

Demonstrating best practice cryptography under EN 18031 comes down to a simple discipline: for every cryptographic mechanism protecting an in-scope asset, write down what it protects, which algorithm and key length you use, and which current, named, dated source says that choice is sound. Then handle the exceptions honestly, justifying deviations under the section that owns them, and state whether your device can be updated when the catalogues move.

The two traps worth repeating are the ones that catch experienced teams. First, good cryptography with missing justifications still fails the decision tree. Second, the catalogue most guidance still recommends, SOG-IS, stopped being maintained in February 2026, so evidence copied from an older template may now cite a dead source. Check both before you sign the Declaration of Conformity.

RedComply turns CRY-1 from a blank page into a structured, guided table. The platform implements the EN 18031 requirement structure directly, including the CRY-1 decision tree with its two decision nodes, so the assessment outcome follows from the answers you give rather than from a manual reading of the standard.

If you are preparing an EN 18031 technical file and CRY-1 is the section you keep postponing, start at redcomply.com and let the structure do the remembering.