For a national CA that issues qualified certificates, the European recommended lists do not settle the ECDSA vs RSA question. RSA-4096 and ECDSA P-384 both sit on the European recommended lists. RSA clears the 3000-bit floor, and P-384 is a recommended named curve. That leaves three things to decide on, in this order: what your HSMs actually sign per second with each algorithm, what your installed base of cards, tokens and eIDAS nodes can verify, and how each choice holds up through the post-2030 move to quantum-safe signatures. This is a judgement with reasons, and the reasons depend on your estate, not on the algorithms in the abstract.
How ECDSA and RSA differ when they sign certificates
RSA bases its security on how hard it is to factor the modulus, and its key size is the bit length of that modulus. ECDSA works over an elliptic curve, and its key size is the bit length of the order of the curve’s base point. ECDSA depends on domain parameters whose validity the signer has to confirm, while RSA uses no domain parameters at all.
The second visible difference is size. Let’s Encrypt (2020) put a P-384 public key at about 48 bytes and its signature at 96 bytes, compared with about 256 bytes each for an RSA-2048 key and signature. Against RSA-4096 the gap is larger still, because an RSA signature is as long as its modulus. Smaller ECDSA keys suit resource-constrained environments. They matter much less to a root certificate that sits in a trust store.
The third difference is in how each one fails. An RSA signature has no per-signature secret. ECDSA requires a unique nonce per signature, and Jančár et al. (Minerva) showed that leaking even a few bits of those nonces can be enough to recover the private key. We come back to this in the token section, because that is where it bites.
Is ECDSA P-384 stronger than RSA-4096?
On paper, yes. FIPS 186-5 rates an ECDSA key with a 384 to 511-bit order at about 192 bits of security strength. Matching that with RSA takes a 7680-bit modulus, according to the NIST key-size table reproduced in the LightDSA paper (2025). BSI TR-02102-1 puts the 128-bit level at roughly 3000 bits for RSA and 250 bits for elliptic-curve keys. RSA-4096 therefore sits above the 128-bit line but below the 192 bits P-384 offers.
The headline strength only counts if the hash keeps up. FIPS 186-5 caps an ECDSA signature’s strength at whichever is weaker, the curve or the hash. ETSI TS 119 312 recommends only elliptic-curve suites whose hash output length equals the curve’s key size. Mozilla’s root store policy requires ECDSA with SHA-384 for a P-384 signing key. So P-384 comes with SHA-384, since a weaker hash caps the signature’s strength.
Both are recommended mechanisms, which ECCG holds adequate against presently known threats. The gap between 128 and 192 bits is not what separates them for a CA built now. A quantum computer breaks both.
What RSA key size should root and intermediate CA certificates use?
For new qualified certificates, ETSI TS 119 312 V2.1.1 says that after 31 December 2026, only RSA keys of at least 3000 bits, or schemes it marks as recommended, may be used. The ECCG Agreed Cryptographic Mechanisms v2.0 (ENISA, 2025) lists RSA with n ≥ 3000 as recommended and n ≥ 1900 as legacy.
The padding scheme matters too. TS 119 312 marks RSA-PSS as recommended and RSA-PKCS#1 v1.5 as legacy, and requires RSASSA-PSS for RSA signatures. The eIDAS interoperability framework sets RSASSA-PSS with 3072 bits as the minimum for certificate signatures. An RSA-4096 hierarchy that still signs with PKCS#1 v1.5 uses a legacy mechanism, however long its key.
Within the hierarchy, issuer keys are chosen at least as strong as the keys they certify. TS 119 312 says CA keys should be chosen at least as strong as the keys they certify. Root certificates also have to last: TS 119 312 notes that self-signed certificates need to hold for more than 10 or 20 years, so quantum resistance belongs in the choice. If your leaves are RSA-3072, a 4096-bit root and intermediate meet that rule. If your leaves are P-384, an RSA-4096 issuer is the weaker link by strength.
Is RSA outdated or being deprecated for certificate signing?
No, the European lists do not deprecate RSA in favour of ECDSA. RSA-PSS and ECDSA sit together in the same recommended tier. What is being phased out is the sole use of classical asymmetric signatures, ECDSA and RSA alike.
TS 119 312 says that where signatures must stay valid beyond 2030, RSA must be used in a hybrid scheme or replaced by a quantum-safe algorithm. It says the same of ECDSA wherever quantum resistance is required. For issuer CA keys, it recommends hybrid CA certificates (alternative public key extensions or composite keys) during the transition.
The timelines point the same way. In its initial public draft IR 8547 (2024), NIST proposes deprecating 112-bit RSA and ECDSA after 2030 and disallowing them after 2035. Keys at 128 bits or more would also be disallowed after 2035. BSI TR-02102-1 says signature methods that are not quantum-safe will only be recommended for hybrid use in future, with the transition due by 2035 at the latest under the EU roadmap.
So the quantum horizon does not settle RSA against ECDSA. It does change what your HSMs must support. NIST notes that hardware modules must be upgraded or redesigned to support PQC algorithms, and Thales TCT states that its Luna HSMs support ML-DSA and ML-KEM. We would weigh PQC readiness of the HSM and the CA software at least as heavily as the classical algorithm.
ECDSA vs RSA performance on a CA’s HSM
On vendor figures, elliptic-curve signing runs faster than RSA-4096. Whether that matters depends on which key in the hierarchy you are talking about.
Thales TCT’s Luna Network HSM page lists RSA-4096 at 350 and 3,500 tps and ECC P-384 at 2,000 and 16,000 tps. The listing does not say which model each column belongs to. These are vendor-stated figures. They describe one vendor’s Luna line only.
Entrust’s nShield 5c data sheet gives RSA-4096 signing at 135, 814 and 2,200 tps across its Base, Mid and High models, but its prime-curve rows cover only 256 and 521 bits. The P-521 row (1,010, 5,977 and 16,164 tps) is the nearest comparison, and P-521 is the heavier curve, so treat it as a conservative stand-in, not a P-384 measurement. The Thales Luna PCIe brief claims over 20,000 ECC and 10,000 RSA operations per second, but the models it specifies are quoted at RSA-2048 and P-256, so it says little about the sizes at issue here.
Software timings, not HSM figures, point the same way: the LightDSA study (2025) measured RSA-7680 signing at about 0.93 s, with P-384 ECDSA signing much faster.
Whether the throughput gap matters comes down to where the signing happens:
- Offline root. It signs intermediate certificates and CRLs, not subscriber certificates, so throughput does not decide its algorithm.
- Issuing CA for citizen certificates. It signs every certificate it issues, at enrolment and renewal. Check it against measured peak issuance, not average.
- OCSP responders and CRL issuers. These sign status information on demand for relying parties.
At the figures above, RSA-4096 gives lower signing throughput per HSM than the elliptic curves. That is a cost and capacity question, not a security one, and only a benchmark on your own HSM model and firmware answers it.
Will ECDSA certificates work with existing smartcards, tokens and relying-party software?
We would settle it by testing against the specific card OS, applet and node versions you have deployed.
The standards point both ways. NIST SP 800-78-5 approves P-256 and P-384 for PIV keys, and it removed RSA-4096 as a signature algorithm for PIV data objects. It also cautions that elliptic-curve signatures may initially limit interoperability. Token firmware matters too: Yubico documents P-384 support in PIV slots 9A, 9C, 9D and 9E, while RSA-3072 and RSA-4096 need firmware 5.7 or later. On a national card, the Estonian eID developer guide lists secp384r1 and brainpoolP512r1 key containers for both authentication and signature keys.
Relying parties and eIDAS nodes are the other half. The eIDAS cryptographic requirements recommend support for NIST P-256, P-384 and P-521 (alongside Brainpool curves) in SAML, and set ECDSA at 256 bits and RSASSA-PSS at 3072 bits as the minimum for certificate signatures. Mozilla’s root store accepts RSA of 2048 bits or more and P-256, P-384 or P-521. Meeting the standard on paper does not guarantee interoperability, as NIST’s caution shows. We would run the full chain through every relying-party stack in scope before committing.
The CA key and the card key do not have to match. In the Estonian hierarchy, EE-GovCA2018 CAs are P-521 but issue P-384 leaves, and SK’s ECC issuers are P-384 while Smart-ID leaves are RSA-6144. A legacy card fleet constrains the leaf algorithm and the verifier software. It does not automatically fix the root’s algorithm.
Choosing ECDSA adds two risks specific to its design:
- Nonce leakage. Minerva recovered full private keys from about 2,100 signatures on smartcard data. The affected card and its chip held FIPS 140-2 and Common Criteria certification, and the authors attribute the flaw to unprotected “fast” ECC routines. Certification is not proof of side-channel resistance. BSI also says resistance must be examined case by case. Deterministic ECDSA (RFC 6979) is an approved variant under FIPS 186-5.
- Domain parameter validation. The signer must obtain assurance that the curve parameters are valid. TS 119 312 also restricts ECDSA to its listed curves.
Which eIDAS and ETSI rules constrain the choice, and how do you document it for an auditor?
Under Regulation 910/2014, compliance runs through reference standards. Commission Implementing Regulation (EU) 2025/1943 sets out the reference standards under which qualified certificate services get the presumption of compliance. EN 319 411-2 specifies the EU qualified certificate policies, such as QCP-n, building on EN 319 411-1. EN 319 411-1 notes that TS 119 312’s cryptographic suite recommendations can be superseded by national recommendations. TS 119 312, in turn, leaves the assessment of the underlying schemes to the ECCG document.
That chain is what the documentation should follow. A choice of algorithm that an auditor can accept, in our view, records:
- The governing list and version. Cite TS 119 312 V2.1.1 and ECCG Agreed Mechanisms v2.0 by version, with the R/L status of the chosen scheme, curve and hash.
- Any national override. Name the national recommendation that applies, or state that none supersedes TS 119 312.
- The suite in full. Write “ECDSA P-384 with SHA-384” or “RSASSA-PSS 4096 with SHA-384”, never just “RSA” or “ECC”.
- Lifetime suitability. Show the key stays suitable for the certificate’s validity period and for the certificates that depend on it.
- Any legacy justification. If a legacy mechanism is kept, ECCG requires a backwards-compatibility justification, and TS 119 312 allows legacy use only where interoperability needs it.
- The quantum plan. Record how the hierarchy moves to hybrid or quantum-safe signing for validity beyond 2030.
- Evidence. Attach the HSM benchmark and compatibility results that drove the choice, plus the record of dual-control root issuance.
- A review trigger. ECCG revises its list every two years and can downgrade a mechanism after a cryptanalytic advance, so the record should name when it is re-checked.
Each line in that list traces a technical choice back to a named requirement and a test record, the kind of approval-grade evidence covered under AI governance and trust.
A decision table for RSA-4096 or ECDSA P-384
| Your situation | Lean towards | Why |
|---|---|---|
| Cards, tokens and nodes verified on P-384; issuing tier near HSM capacity | ECDSA P-384 primary | Higher signing throughput on vendor figures; recommended curve |
| Legacy cards, tokens or node builds without verified P-384 support | RSA-4096 (RSA-PSS) | Recommended at ≥ 3000 bits; fewer verification surprises |
| Mixed fleet during card replacement | Parallel ECC and RSA hierarchies | ECC active with RSA as backup, as SK ID Solutions runs |
| HSM capacity is ample either way | Decided by compatibility | Throughput no longer separates them |
| Signatures must stay valid beyond 2030 | Either, with a hybrid plan | Both need hybrid or quantum-safe replacement |
The dual-root precedent, and what it costs
One national eID scheme already runs parallel ECC and RSA roots. SK ID Solutions runs parallel roots valid from 2021 to 2041: ROOT G1E on ECC P-521 as active, and ROOT G1R on RSA-4096 as backup. Its qualified issuers are ECC P-384 as the primary active issuer, with RSA-4096 issuers held as backup, and its current Smart-ID qualified issuer is available in both ECC P-384 and RSA-4096. Estonia’s newer government card CA, EEGovCA2025, is P-384 end to end, while the older SK RSA-4096 issuers are being phased out.
That model puts P-384 as the primary with RSA-4096 kept as backup. It is not free. Two hierarchies mean two root ceremonies, two sets of HSM partitions and two CRL and OCSP chains. And TS 119 312 recommends hybrid CA certificates for issuer CA keys during the PQC transition.
A related design question is how to scope intermediates so that one compromised key cannot sign for every product line or cohort. We would settle that compartmentalisation alongside the algorithm choice, before the root ceremony.
FAQ
Is Thales an HSM?
Thales makes HSMs, including the Luna Network HSM; Thales TCT says its Luna T-Series HSMs hold FIPS 140-3 Level 3 validation. Thales’s Luna PCIe HSM brief cites a qualified signature or seal creation device (QSCD) listing for eIDAS compliance.
Where is ECDSA used?
The Minerva authors note that ECDSA is used in the TLS protocol, in document signing and in blockchain applications. It is also used in national eID schemes, such as Estonia’s P-384 card hierarchy.
