The cryptographic baseline assumed in every European bid
Late stage of design review. The asset owner's cryptographic reviewer is going through the manufacturer's product security documentation, looking for the algorithm declarations. The document is well-prepared and complete. It lists the protocols the device speaks, the ciphers supported, the key lengths used, the hashing algorithms employed at various points in the firmware.
The reviewer pauses on a particular line. The firmware signature verification — the cryptographic check the controller performs before accepting a firmware update — uses SHA-1 as the hash function and RSA-2048 as the signature algorithm.
The reviewer makes a note. Two issues with that line. First, SHA-1 has been demonstrably broken for collision resistance since 2017 , has been deprecated across every major cryptographic guidance body, and is formally retired by NIST for digital signature use at the end of 2030. The current cryptographic review will not accept it today, regardless of the formal deadline. Second, RSA-2048 sits on the boundary of what is acceptable; NIST SP 800-131A Rev. 2 recommends migration to 3072-bit RSA or to elliptic curve signatures for any device with a service life beyond 2030, which describes essentially every industrial controller being procured in 2026.
The manufacturer's lead engineer is surprised. The SHA-1 was deliberate — chosen for fast computation on the resource-constrained controller eight years ago, never revisited. The RSA-2048 was the standard for the bootloader code at the time, defensible then, on the edge now. Both choices were reasonable when made. Neither survives a current cryptographic review.
This is the cryptographic baseline conversation, and it is the area in which vendor assumptions and EU expectations diverge most quietly. Most of the architectural arguments in this series surface in early conceptual conversations; cryptography, by contrast, often passes through factory acceptance, gets installed at site, and reveals its mismatches only when a security review is conducted six months into operations. The lender's technical adviser opens a finding. The manufacturer's engineering team faces a firmware update that touches the bootloader, deployable only during planned outages, requiring re-certification under the manufacturer's own quality system. The remediation is expensive and slow. The conversation, had at proposal stage, would have cost almost nothing.
The baseline at the transport level
For network communication, the floor expected in any EU-financed project is TLS 1.3 — the current standard, in widespread deployment since 2018, preferred for all new product designs. TLS 1.2 remains acceptable for legacy migration paths but only with a restricted cipher suite list: forward-secrecy key exchange through ECDHE rather than static RSA, AEAD cipher modes (AES-GCM, AES-CCM, ChaCha20-Poly1305), and removal of all CBC-mode ciphers except where mandatory and properly mitigated against known attacks. SSL of any version — SSLv2, SSLv3 — has been deprecated for over a decade and must not be present, even as a configuration option. TLS 1.0 and TLS 1.1 are similarly out of scope.
For asymmetric cryptography, the floor for new designs is RSA-3072 or elliptic curve cryptography on NIST P-256 (or higher), with Ed25519 increasingly accepted for newer implementations. RSA-2048 is acceptable for legacy products under migration but is on the boundary of what should be specified for new equipment. For Diffie-Hellman key exchange, ECDHE on standard curves is the expected choice; finite-field DH should be 2048 bits minimum, but EC variants are now standard practice.
For hashing, the floor is SHA-256, with SHA-384 expected for higher security level zones and SHA-512 acceptable. SHA-1 is not acceptable for any cryptographic purpose — neither for signature verification, nor for HMAC, nor for file integrity checking. The formal NIST retirement deadline is end of 2030, but in practice the asset owner's reviewer will flag SHA-1 use today, not in 2030. MD5 has been broken since 2004 and has no legitimate cryptographic use in industrial equipment.
For symmetric encryption, AES is the floor, with AES-128 acceptable for most use cases and AES-256 expected for SL-T 3 zones and above. ChaCha20 is acceptable as an alternative, particularly on resource-constrained devices that struggle with hardware-accelerated AES. 3DES is unacceptable. DES, RC4 and any export-grade cipher are unacceptable and should not be present in firmware even as fallback options.
For digital signatures — the most consequential application of asymmetric cryptography in industrial equipment, because firmware signature verification depends on it — ECDSA on NIST P-256 (or higher) is the standard choice, with Ed25519 increasingly preferred for newer designs and RSA-3072 acceptable. The signature algorithm used by the bootloader to verify firmware updates is one of the cryptographic checks the asset owner's reviewer will examine most carefully, because a compromised firmware signature mechanism compromises every other security control the device has.
These are not parameter choices to be left to deployment configuration alone. The device must support these algorithms in firmware. Weaker algorithms should not be available as fallback options the deployment configuration must remember to disable. Where weak algorithms are present for historical compatibility — a TLS 1.2 server that can still negotiate SHA-1 with old clients, an HMAC implementation that retains MD5 for legacy interoperability — their removal must be planned as part of the product roadmap, not left as a future maintenance topic.
Certificates and PKI integration
The cryptographic algorithms are one half of the baseline. The other half is how the device handles the cryptographic identity infrastructure that the asset owner operates.
A persistent issue with industrial equipment is the self-signed or vendor-rooted certificate baked into the firmware at manufacture. A device that ships with a self-signed certificate and offers no facility for replacement is a device whose cryptographic identity cannot be integrated into the asset owner's public key infrastructure. Every TLS handshake the device performs falls outside the asset owner's chain of trust; every certificate validation requires explicit override; every audit of the cryptographic boundary returns the same finding.
The expectation is that devices accept certificates issued by the asset owner's PKI, deployed through the asset owner's certificate enrollment process. The protocols for that enrollment are standardised — SCEP (Simple Certificate Enrollment Protocol), EST (Enrollment over Secure Transport, RFC 7030) , and increasingly ACME (Automated Certificate Management Environment, RFC 8555) — and the device should support at least one of them. A device that requires manual certificate import through a vendor-specific tool may technically pass acceptance, but it creates operational friction that the asset owner's identity team will surface during onboarding and ongoing operations.
Certificate rotation must be supported. Long-lived certificates — five years, ten years, the device's service life — are increasingly unacceptable. The expectation in modern PKI is short-lived certificates, often 90 days or less for connection-level credentials, rotated automatically through the enrollment protocol. A device that supports only certificates with multi-year lifetimes is a device incompatible with the asset owner's PKI policy.
The device must also support certificate revocation in a way the asset owner can verify — either through OCSP (Online Certificate Status Protocol) or through Certificate Revocation List distribution. A revoked certificate that the device continues to trust is a security failure the asset owner cannot tolerate. The verification path must be configurable: pointing at the asset owner's revocation infrastructure, not at the manufacturer's.
Mutual TLS — where both sides of a connection present and verify certificates — is expected for machine-to-machine connections in higher security level zones. Server-side-only TLS is acceptable for some use cases but inadequate for control-system communication where both endpoints need cryptographic identity.
The reference standard pulling this together is IEC 62443-4-2 component requirement 1.8 (public key infrastructure certificates) and CR 1.9 (strength of public key authentication), with the latter's higher security level enhancement requiring hardware-based protection of authentication keys.
Hardware root of trust and secure boot
The cryptographic baseline is increasingly anchored at the hardware level, not just in firmware configuration.
A hardware root of trust — a chip or chip area dedicated to cryptographic operations and key storage, separated from the general application processor — is the foundation. Common implementations include TPM 2.0 (Trusted Platform Module, ISO/IEC 11889), ARM TrustZone with a secure element, dedicated secure cryptographic chips (Microchip ATECC608, Infineon OPTIGA, NXP A71CH and their successors), and FPGA-based hardware security modules. The role is consistent: provide a tamper-resistant location for storing private keys, performing cryptographic operations, and anchoring the chain of trust for secure boot.
Secure boot is the discipline that uses the hardware root of trust to verify, cryptographically, that every stage of the boot process — bootloader, kernel, root filesystem, application — has been signed by an authorised party before it is allowed to execute. A modified or unsigned image is rejected at the first verification step. The chain of trust extends from the immutable hardware root through every loaded component, with each stage verifying the next before passing control. Tampering at any point breaks the chain and prevents the device from booting.
For SL-T 3 zones and above, hardware root of trust and secure boot are increasingly assumed. A device without these features can be deployed into lower security level zones with compensating controls, but its presence in an SL-T 3 zone requires explicit risk acceptance an asset owner is increasingly unwilling to grant. The trend across the industry is toward hardware-anchored security as standard practice, with the cost of inclusion having fallen to the point where it is no longer a meaningful BOM consideration on most controller-class hardware.
The cryptographic keys held in the hardware root of trust are the device's identity. They are provisioned at manufacture, ideally in a controlled environment with auditable processes. The device's certificate, issued by the asset owner's PKI, is bound to a key pair whose private key never leaves the secure element. This binding is what makes the device's cryptographic identity trustworthy — the private key cannot be extracted, cloned or substituted, even by an attacker with physical access to the device.
Post-quantum and the long view
A topic the cryptographic baseline conversation now touches, where it would not have five years ago, is post-quantum cryptography.
The risk is well-defined. Sufficiently large quantum computers — when they exist, on a timeline still debated but generally placed somewhere between 2030 and 2040 — will break RSA and elliptic curve cryptography. Encrypted data captured today, stored, and decrypted later will be readable. Authenticated connections established today, with logs preserved, will be retroactively impersonable. The "harvest now, decrypt later" attack model is taken seriously by intelligence services and increasingly by lender risk teams underwriting twenty-five-year assets.
NIST completed the first round of post-quantum cryptography standardisation in August 2024, publishing FIPS 203 (ML-KEM, formerly CRYSTALS-Kyber, for key encapsulation), FIPS 204 (ML-DSA, formerly CRYSTALS-Dilithium, for digital signatures), and FIPS 205 (SLH-DSA, formerly SPHINCS+, for hash-based signatures). The European cryptographic community has broadly endorsed these algorithms. The transition is now an engineering matter rather than a standards matter.
The expectation for new industrial equipment in 2026 is not that products implement post-quantum cryptography today — that would be ahead of mainstream practice and may not interoperate with the rest of the ecosystem. The expectation is that manufacturers have a credible roadmap for it, that they are tracking the standardisation outcomes, and that their cryptographic agility — the ability to swap algorithms without redesigning the product — supports a future migration. Hybrid TLS 1.3 implementations, combining a classical algorithm and a post-quantum algorithm in a single handshake, are increasingly seen in serious deployments and are likely to be the migration path for industrial systems.
A device whose cryptographic implementation is hard-coded — algorithms compiled into firmware with no facility for replacement, key sizes fixed, ciphers immutable — is a device that cannot make the post-quantum transition without firmware replacement. For equipment with a twenty-five-year service life, this is a material commercial risk the lender's risk team will price into their assessment.
At proposal stage
A manufacturer's bid that includes a cryptographic configuration document — listing the algorithms supported, the protocols implemented, the key management approach, the hardware root of trust if present, the secure boot chain if present, the certificate enrollment protocols supported, and the post-quantum roadmap — is a bid that has anticipated the conversation. The lender's technical adviser reviews the document, identifies any specific concerns, and the conversation proceeds.
A manufacturer's bid that does not address cryptography, or that addresses it generically with phrases like "industry-standard encryption" or "secure protocols supported", signals that the team has not yet considered the specifics. The cryptographic review will surface gaps; the gaps will require firmware modifications; the firmware modifications will need to be planned, tested and deployed before commissioning. The cost of the modifications is rarely large in absolute terms. The schedule impact, if surfaced late, can be considerable.
The cryptographic baseline is, in some ways, the most universal of the topics in this series. It does not depend on regulation in the way the disclosure programme or the bill of materials do. It does not depend on the project structure in the way the network and substation boundaries do. It is a property of the equipment, applicable to every deployment, every customer, every jurisdiction. A manufacturer that builds cryptographic discipline into their product line is a manufacturer that has reduced friction across their entire market — EU-financed and otherwise.
The next article picks up the engineering function that cryptography supports but does not, on its own, deliver: the identity and access model for engineers, service accounts and machine-to-machine connections, where the manufacturer's habit of named-team access through shared credentials meets the asset owner's expectation of named-person access through their identity infrastructure.
This article reflects the cryptographic landscape at publication. NIST guidance on algorithm deprecation continues to evolve, particularly around the SHA-1 retirement deadline and post-quantum migration timelines. References to commercial secure element vendors are illustrative rather than endorsements. If a citation has rotted or a clause has moved, LinkedIn is the way to flag it.