A note on scope before we start. This post is not really about Italian law; the Cassazione ruling is just a detailed, recent judicial treatment of the problem, whose conclusions can shift well beyond the borders of Italian law. It is about a problem every organization running digital contract execution eventually runs into, wherever it operates: how do you prove that a party specifically and knowingly agreed to a clause that puts them at a disadvantage – e.g. a limitation of liability or a jurisdiction clause – when the whole contract was concluded with a few clicks? Most legal systems that require heightened protection for this kind of clause face the same practical question, and the six implementation patterns discussed below are portable well beyond the jurisdiction where they happen to have been tested in court.
Contracts are moving online faster than most compliance frameworks can keep up. Procurement, energy supply, banking products, insurance policies, more and more of the paperwork that used to be signed on paper is now accepted with a click, a code, or a digital signature, often across several jurisdictions at once. It is exactly this shift that makes the ruling worth close attention well beyond the borders of Italian law.
The starting point: what the Italian Supreme Court said
The Corte di Cassazione is Italy’s supreme court, whose rulings on legal principle (rather than on the facts of a single case) shape how lower courts, and in practice how businesses, interpret the law going forward. With order no. 20945/2026, it ruled on a question with no shortage of equivalents elsewhere: when is a burdensome clause validly approved in a contract concluded entirely online?
The case concerned an electricity supply contract concluded online between two businesses, with a jurisdiction clause approved through a “double flag”, two checkboxes ticked with a mouse click. The Court found this insufficient [1]. Its reasoning rests in part on Article 13 of Legislative Decree 70/2003 [2], which extends the ordinary rules on contract formation to agreements concluded electronically for goods or services of the information society, meaning that concluding a contract online is, by itself, no reason to relax the specific-approval requirement that would apply offline.
The reasoning, in short: even in a digital environment, the approval of what Italian law calls a clausola vessatoria [3] – an onerous clause under Article 1341, second paragraph, of the Italian Civil Code [4] – must remain specific; the Court accepts that such approval can be given through an electronic signature, even a simple one; but ticking a checkbox, however many times – the Court states – does not fall within the eIDAS Regulation’s definition of an electronic signature [5], because it does not produce electronic data linked to the signatory in a way that qualifies as such. As a result, plain point-and-click cannot prove either that the act is attributable with certainty to the party, or that consent to that specific clause was given knowingly. As one illustrative example of a suitable solution, the Court cites entering a one-time code sent by SMS or email [1], though the underlying principle is about the nature of the electronic event generated, not about any single authentication mechanism being mandatory.
A closer look: the role of “forma scritta ad substantiam”
To understand why the Court draws the line where it does, it helps to zoom out to the broader architecture of Italian contract law on written form, an architecture the ruling deliberately keeps in the background but that fully explains its reasoning. It is also a useful reference point for any jurisdiction that distinguishes, as most do in some form, between validity requirements and mere evidentiary weight.
Italian law distinguishes between contracts that require written form ad substantiam, as a condition of validity, under Article 1350 of the Civil Code [4] (real estate transfers, certain long-term leases, and other listed categories), and contracts for which written form is not a validity requirement but may still matter for evidentiary or contractual-fairness purposes.
For the first category, the bar is high and does not bend: only a qualified electronic signature or a digital signature (the Italian-specific variant built on a public/private key pair) can validly substitute a handwritten signature, on pain of nullity. A simple or even an advanced electronic signature is not enough where the law requires ad substantiam form.
For the second category, which is where this case sits, the threshold is lower. Article 20, paragraph 1-bis, of the Digital Administration Code (Legislative Decree 82/2005, “CAD”) [6] grants full written-form value and the evidentiary effect of Article 2702 of the Civil Code [4] to a digital document only if it is signed with a digital signature, a qualified electronic signature, or an advanced electronic signature, or generated through a qualified electronic identification process compliant with AgID rules, capable of ensuring the document’s security, integrity and unambiguous attribution to its author. Outside these cases, the document’s evidentiary value is left to the free assessment of the judge, based on the security, integrity, and immutability of the document itself.
This is precisely the gap the Cassazione ruling addresses for onerous clauses: because approving one in a non-ad substantiam contract does not require full written-form value, a simple electronic signature can be enough, but it still has to actually be one. A checkbox tick, in the Court’s view, simply is not.
A legitimate doubt: was the Court too strict?
It is worth revisiting an observation made by Giusella Finocchiaro and Laura Greco in a commentary on the ruling published in Il Sole 24 Ore [7]. The authors note that the eIDAS Regulation’s definition of an electronic signature [5] was deliberately drafted to be broad and technology-neutral, precisely so as not to rule out in advance signing methods not yet imagined when it was written. Excluding point-and-click altogether from the category of electronic signatures is therefore far from a foregone conclusion. It is worth noting, in passing, that the original 2014 Regulation has itself since been amended by “eIDAS2” [5], which extended the framework with the European Digital Identity Wallet and updated several provisions on qualified trust services, a reminder that this is a fast-moving area of law even at EU level, well beyond the Italian case discussed here.
There is a second, arguably more useful, observation for anyone who works with these processes daily: the Cassazione denies validity to the checkbox tick because it allegedly fails to prove that the act is attributable to the contracting party. But attributability of a signature does not depend only on the signing act in isolation, it also depends on how the signatory got there: whether they were identified beforehand, whether the session was tracked, whether a solid authentication path exists upstream. The judgment does not report every detail of the signing process used in that specific case. This leaves genuine interpretive room, and it counsels caution both to those who would dismiss point-and-click as always insufficient and to those who would still consider it acceptable without looking at the surrounding process.
That said, the Court’s signal is clear and should be taken seriously: relying solely on a ticked checkbox is building on unstable ground. The useful question, then, is not “do we need to change everything?” but “what level of robustness does this specific contract, this specific counterparty, this specific risk actually require?”
Four scenarios with two optional reinforcement, not only one
Reclassifying the technical options available today on a modern digital signature platform produces six distinct configurations. The first four are alternative ways of approving the onerous clause itself; the last two are not alternatives to each other but reinforcing steps that address a related, different problem, making sure the party actually had the opportunity to access the document before signing it, and can be layered on top of whichever approval scenario is chosen. We illustrate them using Namirial’s own signing solutions, Namirial Sign Enterprise (NSE) for remote/enterprise signing and Namirial Sign Personal for individual use.
On approving the onerous clause
1 Baseline solution – point-and-click acceptance The party ticks a checkbox dedicated to the onerous clause. It is worth noting that this scenario is not always the crude, unverified click it might sound like: it is also the mechanism behind much more sophisticated “headless” flows, where the checkbox sits on top of a session that has already established strong identification and continuous authentication of the party, an approach several vendors, and a growing part of the market, are actively pushing as the frictionless default. That context can matter a great deal for the imputability question discussed above. What it does not change is the Court’s specific finding in this case: on the record before it, the double flag was found insufficient to prove that consent to the clause was given knowingly. We should keep in mind that Article 25 (1) of eIDAS Regulation clearly states that an electronic signature shall not be denied legal effect and admissibility as evidence in legal proceedings solely on the grounds that it is in an electronic form or that it does not meet the requirements for qualified electronic signatures.
2 Intermediate solution – a dedicated authentication step for approving the clause The party completes a distinct authentication step, the specific mechanism (e.g. a one-time code, or another factor available on the platform) is a choice to evaluate based on the implementation scenario in place, specifically to approve the onerous clause, separate from whatever authenticates the rest of the contract. This is the scenario the Cassazione describes almost verbatim as suitable: it generates an electronic event attributable to the signatory and separate from the rest of the acceptance flow. In terms of user experience it introduces one manageable extra step.
3 Advanced solution – signing the clause with the same certificate A single qualified signature certificate is used to generate several distinct signing events on the same document: one specifically on the onerous clause, one or more on the other contractual fields. On a remote signing platform such as Namirial Sign Enterprise (NSE) this happens within a single session: the number of signatures stays identical to what the contract already requires, the only change being that the onerous clause now receives its own signing event instead of being absorbed into the overall document seal. On graphometric signature this behaviour is already native: as many strokes as there are signature fields, including the onerous clause. This solution requires no second certificate and fully satisfies the specificity requirement, with essentially the same user experience as today.
4 Reinforced solution – signing with a new, dedicated qualified certificate A second certificate, separate from the one used for the other fields, is issued and applied specifically to the onerous clause. Two variants exist here, with slightly different costs and levels of robustness:
• 4a – qualified signature plus a named advanced electronic signature. The qualified certificate remains on the other contractual fields, while the onerous clause is signed with an advanced electronic signature that is still nominal and reliably attributable to the signatory, but without the certification level (and cost) of a qualified signature. This is an interesting middle ground: it preserves the separation of the signing event that the specificity principle implicitly calls for, without duplicating the economic and procedural burden of two distinct qualified certificates.
• 4b – double qualified signature, two genuinely distinct certificates. Both certificates, the one on the other fields and the one on the onerous clause, are qualified signature certificates, issued as two separate credentials, each with its own identity binding. This is the strongest option from an evidentiary standpoint, but also the most expensive to implement, since it requires issuing and managing two distinct qualified certificates for the same signatory on the same document.
A word of caution on 4b, because it is easy to blur it with scenario 3: if what is actually deployed is a single-use (“disposable”) qualified certificate applied twice in sequence within the same signing session, one use on the onerous clause, one on the other fields, net of each carrying its own timestamp, that is not a genuinely reinforced scenario. It is, in substance, scenario 3 again: one certificate, multiple signing events. Scenario 4 only earns its extra evidentiary weight if the two certificates are truly distinct credentials (qualified or not), not two uses of the same one-time certificate.
To be clear on both variants: neither is required by the legal principle stated in the ruling, the Court explicitly refers to an electronic signature that can be “light” (meaning not advanced nor qualified), and the single-certificate, multi-field scenario (point 3) is already fully adequate. These options make sense not as a compliance obligation but as an additional safety margin, for organizations that want to protect themselves against a possible future tightening of the case law, for instance in consumer contracts, where the risk adds to that already imposed by unfair-contract-terms regimes such as the EU’s or the UK’s.
Reinforcing the process: proving the document was actually made available
Specificity of approval is one side of the coin; the other is proving that the document was actually made available before signing. Unlike scenarios 1-4, which are alternative ways of approving the same clause, scenarios 5 and 6 are not mutually exclusive options, they are two reinforcing layers that can be added on top of whichever signing scenario is chosen, each strengthening the evidence a step further.
5 Reinforcing step – mandatory download before signing, tracked in the audit trail On top of any of the four signing scenarios above, the platform can be configured to prevent signing unless the document has first been downloaded, logging the event in the audit trail. To make this evidence genuinely useful in a dispute, the log should capture more than just the fact that a download happened: it should record the exact file name and version downloaded, and the file size (in KB) actually transferred, alongside the timestamp and session identifier. This turns a generic “document was downloaded” entry into evidence that the specific, final version of the contract, not a draft, not a partial transfer, reached the signer before they signed. This is a low-impact addition from a user-experience standpoint, one extra click, that produces meaningfully stronger evidence than a bare download flag.
6 Reinforcing step – sending the document by certified email Going a step further than a tracked download, the document can be sent to the party through a channel that independently guarantees a certified date, content integrity, and proof of delivery, before the signing process even begins. A service such as Namirial Notify EviMail is built exactly for this: it records evidence for processing, sending, delivery, opening, and, where configured, the recipient’s explicit acceptance or rejection of the content, each with its own timestamp. This step can be layered on top of scenario 5, or used on its own; either way, it moves the proof of availability from a log internal to the signing platform to an independently verifiable, third-party channel.
It is fair to flag this scenario’s limits honestly: for most high-volume digital signing flows, scenarios 1 through 5 already cover the specificity and availability requirements at the platform level, and adding a separate certified-email step is not something every contract needs. Scenario 6 earns its place mainly at the edges, genuinely high-stakes disclosures, or situations where an organization specifically wants a channel independent of the signing platform itself, more than as a routine addition to everyday contracts. As with the reinforced signing scenario above, two variants exist here, with different evidentiary weight for the document transmission itself:
• 6a – standard electronic registered delivery (eRDS). Used in its ordinary configuration, EviMail already produces solid, timestamped evidence of sending, delivery, and content integrity, sufficient for most commercial disputes over whether and when a document was transmitted.
• 6b – Qualified Electronic Registered Delivery Service (QeRDS). Namirial Notify is also certified as a QeRDS provider under eIDAS [5]. At this level, both sender and recipient are reliably identified as part of the transmission itself, and the service benefits from the qualified trust service presumption under eIDAS: the data’s integrity and the accuracy of the date and time it indicates are presumed, and the transmission is recognized as sent and received by the identified parties, with the corresponding legal effect enforceable across the EU. Where the transmission of a specific document is likely to be contested, not just its content, but the very fact that a given counterparty sent or received it, 6b is the variant that removes the most doubt.
Choosing between the two is itself a scenario-mapping decision, not a default: for routine notices, 6a is normally proportionate; for higher-stakes disclosures, the final version of a contract with onerous clauses, a termination notice, a regulatory communication, the added certainty of 6b is usually worth the extra step. Layered on top of a tracked download (scenario 5), either variant adds a further, independently verifiable layer of enforceability against third parties, particularly useful when the contract is likely headed for litigation, or when the organization operates in sectors (banking, financial services, insurance) where traceability of pre-contractual disclosure is already subject to specific scrutiny.
Matching the scenario to the use case
Faced with a ruling like this, the risk runs in two opposite directions. On one side, underestimating the signal and continuing to rely on plain point-and-click for material onerous clauses, banking on the interpretive uncertainty the Cassazione itself acknowledges remains open. On the other, overselling: presenting the most expensive option (the double certificate) as the only compliant one, when the ruling itself indicates that far less is required.
The right choice depends on the contract, the counterparty, and the sector. The table below sketches how the six scenarios tend to map onto common real-world situations, as a starting point for discussion, not a rigid rule:
Mapping the scenario to the use case, before choosing one by default, is already the most important part of the compliance work, and it is a decision worth revisiting as a contract’s risk profile changes, not one to make once and forget.
It is also worth stressing that the scenarios above are not an either/or menu. They can be combined, and combining them pushes the cumulative evidentiary weight further still: pairing the baseline flow with a reinforced signature step (1+4), or adding certified email delivery on top of that (1+4+6), produces a stronger evidentiary record than any single scenario taken in isolation, each additional, independent piece of evidence makes the overall record harder to challenge. None of this is legally required according to Cassazione’s ruling. Stacking scenarios is a matter of proportionality and risk appetite, not compliance, a deliberate choice to trade some extra friction, or cost, for a record that stands up even against a particularly well-resourced or persistent challenge.
References
[1] Corte di Cassazione (Italian Supreme Court), order of 20 June 2026, no. 20945.
[2] Legislative Decree 9 April 2003, no. 70, implementing Directive 2000/31/EC (the E-Commerce Directive) in Italy, Article 13 of which extends ordinary contract-formation rules to contracts concluded electronically for goods or services of the information society.
[3] A quick terminology note for readers outside Italy: Article 1341 c.c. is a formal requirement, it lists specific categories of clauses (limitation-of-liability, termination, forfeiture, jurisdiction, tacit renewal, arbitration, and others) that need a distinct, specific approval regardless of whether their content is actually unbalanced, and it applies to business-to-business contracts too, exactly as in this case. That is a different animal from the EU/UK doctrine of “unfair contract terms” (Council Directive 93/13/EEC [8]; in the UK, now under the Consumer Rights Act 2015 [9]), which involves a substantive fairness test and applies to consumer contracts specifically. The two concepts do overlap in B2C settings, as we’ll see later, but conflating them for a B2B case like this one would be misleading.
[4] Italian Civil Code (Codice Civile), Articles 1341 (specific approval of onerous clauses), 1350 (contracts requiring written form ad substantiam), and 2702 (evidentiary effect of a privately authenticated document).
[5] Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market (“eIDAS”), as amended by Regulation (EU) 2024/1183 of 11 April 2024 (“eIDAS2”), which introduced the European Digital Identity Wallet framework and updated several provisions on qualified trust services.
[6] Legislative Decree 7 March 2005, no. 82 (Digital Administration Code, Codice dell’Amministrazione Digitale, “CAD”), in particular Article 20, paragraph 1-bis.
[7] G. Finocchiaro, L. Greco, Contratto telematico e approvazione delle clausole vessatorie, sul Point&click la Cassazione frena, Il Sole 24 Ore – Norme & Tributi Plus Diritto, 30 June 2026.
[8] Council Directive 93/13/EEC of 5 April 1993 on unfair terms in consumer contracts.
[9] UK Consumer Rights Act 2015, Part 2 (Unfair Terms), which replaced the Unfair Contract Terms Act 1977 for consumer contracts.
