The PIN that cannot be delegated — Smart-ID, AI agents, and eIDAS

Smart-ID does not work the way a password manager works. There is no stored secret an agent could copy once and replay forever. The qualified-signing key never exists as a single value anywhere: SK’s terms define the private key as something whose value "is never generated" and which "exists only in the form of its components" (TCU, definitions). One component lives in the app on the subscriber’s phone, protected by the PIN; the signing operation itself runs as a threshold protocol with SK’s server-side signing module.

That division is spelled out in SK’s remote-QSCD service practice statement (rQSCD SPS). The app’s part of the private key is "protected by Subscriber’s PIN and Subscriber needs to enter the PIN to the [app] for each transaction", and the PIN value is never stored by the app (rQSCD SPS §6.2.8.1). The PIN and its derived AES key are deleted from the app’s memory after a single key-pair operation (rQSCD SPS §6.2.9.1). The activation data (SAD) that lets the signature module act "is passed to SAM in the Signature Activation Protocol", which is designed so that SAD "can [be] submitted only under sole control of the Subscriber by means that are in the possession of the Subscriber" (rQSCD SPS §6.2.8). The public FAQ states the same in plainer language: PIN1 authenticates, PIN2 signs, and "PIN-codes are not stored anywhere" (Smart-ID FAQ, "PIN codes: what are they?").

For both PINs, each use of the key requires a fresh, human-supplied activation secret at the moment of use. There is no persistent unlocked state for an agent to steal or share.

The contract between SK and the subscriber is explicit about where that leaves automation and third-party use. It starts at issuance: the qualified Smart-ID "cannot be issued to a representative" (TCU §1.5). The terms and conditions for qualified Smart-ID certificates then prohibit, among other uses: enabling other parties to use the subscriber’s private key (TCU §3.1.3); enabling the certificate issued for electronic signing to be used in an automated way (TCU §3.1.4); and, in the rQSCD service practice statement, enabling the activation data to be used in an automated way (rQSCD SPS §1.4.2).

The subscriber-side duties run the same direction. The subscriber must "use the Smart-ID App that is distributed by SK" (TCU §5.2.4), which is also where the practice statement says the PIN is entered for each transaction (rQSCD SPS §6.2.8.1). The subscriber must ensure the private key "is used under his/her control" (TCU §5.2.8), must inform SK and revoke the certificates if the key may have been used without authorisation (TCU §5.2.11), and must revoke immediately if the private key or a PIN code "has gone out of his/her possession" (TCU §5.2.12). The Smart-ID security guidance tells users the same thing in non-contract language: do not share PIN1 or PIN2 "with anyone, not even family members or friends", and never enter a PIN for a transaction you did not initiate (Smart-ID FAQ, "How to keep your smart device and Smart-ID safe?").

Which clause fires depends on the design. An agent that holds the PIN or activates the key without the subscriber entering it per transaction is a third party using the key material (TCU §3.1.3) and doing so automatically (TCU §3.1.4, rQSCD SPS §1.4.2). An agent that only relays the PIN is arguably not automated use, but it breaks TCU §5.2.4 and rQSCD SPS §6.2.8.1, which require the PIN to be entered into SK’s own app. In the author’s reading it also engages the revocation duty under TCU §5.2.12, because the PIN has passed through software the subscriber does not control; whether keystrokes relayed that way count as the PIN having "gone out of his/her possession" has not been tested. TCU §5.2.11, which covers use without authorisation, applies when the agent acts without the subscriber’s consent. A subscriber who wired the agent up has authorised the use, which puts the contractual risk on them; whether the agent vendor faces separate product-liability or consumer-law exposure is outside this reading.

For authentication, the rules above are contractual. For signing, a second layer applies, because Smart-ID’s signing certificate is a qualified certificate (TCU §3, certificate types) and the signature is meant to be a qualified electronic signature (QES).

The eIDAS Regulation (Regulation (EU) No 910/2014, as amended by Regulation (EU) 2024/1183) defines an advanced electronic signature as one that, among other things, is "created using electronic signature creation data that the signatory can, with a high level of confidence, use under his sole control" (Article 26(1)(c), as renumbered by Regulation (EU) 2024/1183). A qualified electronic signature is an advanced signature created with a qualified signature creation device and a qualified certificate (Article 3, definitions), and under Article 25(2) it "shall have the equivalent legal effect of a handwritten signature". The 2024 amendment also moved the rules for managing a signature creation device on the signatory’s behalf out of Annex II into a new Article 29a; SK’s separate rQSCD practice statement belongs to that regime.

On the better reading, which Article 32(1)(h) supports by requiring validation to confirm that "the requirements provided for in Article 26 were met at the time of signing", the consequence attaches to the signing moment. Sole control is then not a property of the person who clicks "I consent" on a settings screen: the signature creation data must be under the signatory’s control when the signature is created. Annex II(1)(d) points the same way, requiring a qualified signature creation device to ensure that the creation data "can be reliably protected by the legitimate signatory against use by others". On that reading, if an agent activates the signing key, the signature is not created under the signatory’s sole control, so it is not an advanced electronic signature under Article 26, so it cannot be a qualified electronic signature, and the Article 25(2) equivalence does not attach. A signature produced that way may still carry whatever evidential weight national law gives it under Article 25(1), but it has left the regime that makes it the digital equivalent of a handwritten signature.

The point is not settled. Article 26(1)(c) says the signatory "can" use the data under sole control, and that capability wording also supports reading sole control as a design-level guarantee of the certified signing device rather than a test of each signing moment. On the design reading, a signature produced through a certified device will in practice be treated as qualified unless sole control is affirmatively challenged. No Estonian court has ruled on a signature produced by an AI agent (Riigi Teataja search, 4 October 2026), and the author found no guidance from the Commission, ENISA or the EDPB on AI agents creating signatures. The nearest Estonian case law concerns people, and it runs against the holder. The Supreme Court presumes that a declaration made with a person’s ID card and PIN codes was made by that person, who must prove otherwise, for example that the card and codes left their possession without fault and against their will (RKTKo 2-16-124450/77, 16 December 2019, para 22). Someone who hands the card and codes over voluntarily must accept that the recipient can make declarations in their name that the other party has no reason to doubt, and the handover may amount to a general authorisation (para 23). A transaction made under another person’s identity is void unless that person ratifies it (RKTKo 3-2-1-135-16, para 16), but in 2024 the court separated codes obtained by deception, which grant no authority, from codes handed over so that transactions could be made with them (RKTKm 2-23-11584/18, paras 10–11). These rulings decide who is bound by a contract, not whether the signature is qualified under eIDAS. That does not rescue the PIN handover; the contract cases make it worse. Under either reading, handing the activation secret to an agent removes the per-operation, high-confidence control that the certification was built on. EU law has recently restated that control: Implementing Regulation (EU) 2025/1567, which sets the reference standard for remote signature-device management under Article 29a from 19 August 2027, says the standards must ensure that "signatories have sole control, with a high level of confidence, over the use of their electronic signature creation data" (recital 3). Validation software does not test who entered the PIN, so an agent-made signature will usually still verify; since Regulation 2024/1183, Article 32(1) also presumes the validation requirements, including point (h), are met when validation follows the referenced standards. The dispute, when there is one, happens later, and the presumption leaves the subscriber to explain why a signature made with their certificate should not stand.

One caveat on scope: eIDAS sole control governs signatures, not sessions. PIN1 authentication is not a signature, and nothing in eIDAS stops a user from granting an agent a token that their own authentication produced. What the contract stops is the agent performing the authentication itself: TCU §3.1.3 prohibits enabling another party to use the private key, and that clause covers both certificates, not just the signing one. Delegating the result of authentication and delegating the act of authenticating are different operations, and the pattern recommended below depends on that distinction.

The counter-argument is usually some version of "we’ll issue the agent a delegated credential". The phrase sounds technical and modern, which makes it a convenient wrapper for a PIN handover. It is worth being precise about what it can and cannot mean.

Delegation of authority and delegation of a credential are different operations. The first means the user authorises the agent to act within a defined scope. The second means the agent can activate the user’s key or produce a qualified signature on its own. Nothing in the framework forbids the first. The provisions in the two sections above forbid the second.

A delegated credential that the agent can activate without the human is not a delegation in any sense the regulation recognises. It is a credential handover, and the documents above treat a credential handover as a revocation event, not a design option. A delegated credential that still requires the human to perform the PIN step at signing time is real delegation, but it is not new technology: it is the ordinary consent flow with extra machinery around it, and the PIN step is precisely the part the agent cannot absorb.

In TLS, "delegated credentials" (RFC 9345) mean something else: a short-lived key presented on behalf of a certificate holder so that the certificate’s own key stays out of day-to-day use. It is a TLS mechanism, used mostly by servers and optionally by clients, with nothing to say about a human’s signature PIN. When someone proposes "delegated credentials" for agent signing, ask which protocol they mean.

The identity world solved this general problem years before agents existed. OAuth 2.0 (RFC 6749) was designed to give third parties scoped access without handing them the user’s credentials. It replaces credential sharing with access tokens: the user authenticates once, and the third party receives a token limited in scope instead of the credential itself. Short lifetime, audience restriction and revocation are not guarantees of OAuth as such: RFC 6749 only recommends that the server return expires_in, audience restriction comes from separate mechanisms such as resource indicators (RFC 8707) or the aud claim of JWT access tokens (RFC 9068), and revocation from RFC 7009. They are properties of a deployment profile that the issuer and the service must choose and enforce. RFC 8693 extends the model to token exchange with delegation or impersonation semantics.

Mapped onto Smart-ID, the compliant pattern is: (1) the user authenticates with Smart-ID (PIN1) to the service that owns the agent, as a human; (2) that service issues the agent a scoped token representing the user’s authorisation for a defined task set, never the user’s Smart-ID credential. Rich Authorization Requests (RFC 9396) describe such a task set more precisely than plain scopes. The recommended profile makes that token short-lived, audience-restricted and sender-constrained to the agent where possible, with DPoP (RFC 9449) or certificate-bound tokens over mutual TLS (RFC 8705); these are settings the issuer and the service must configure and enforce, not defaults; (3) for anything that must be a qualified electronic signature, the flow stops and the user signs with Smart-ID (PIN2) themselves, on their own device, with the transaction details in front of them. Where a task needs fresh human approval but not a signature, OpenID Connect Client-Initiated Backchannel Authentication (CIBA) is the standard way for the service to ask the user on their own device mid-task.

The last step is the one that decides compliance. The PIN is entered only into the Smart-ID application itself. Agent software never captures, relays, or stores it, and the user approves only what the Smart-ID app renders for the transaction the relying party initiated. Any prompt rendered by the agent is a replay of the signing-relay class that this site’s Smart-ID research describes.

Every document cited in this report is compatible with steps 1 and 3, and all of them weigh against a design in which step 3 happens without the human. The OpenID Foundation’s 2025 paper on identity management for agentic AI takes the same approach of delegating authority while the credential stays with the user, and lists the gaps that remain open, such as recursive delegation between agents.

Reading the documents is not the same as holding the line, and three limits deserve to be stated plainly.

First, this is a document-level analysis. A contract clause does not enforce itself: the mechanisms that actually stop an agent from using a leaked PIN are the same ones that stop a fraudster, and the site’s prior Smart-ID research shows how the approval layer can fail socially even when the protocol holds. An attacker who can talk a user into approving a transaction does not need to automate the PIN at all. Social engineering is a separate problem, and that earlier research is the better reference for it.

Second, "compliant" and "enforced" are different words. A bank or service provider may tolerate automation in practice, particularly for low-risk PIN1 flows, and SK’s own documents are what SK publishes rather than what every relying party audits. Banks also layer PSD2 strong customer authentication rules on top for payment contexts, which this report does not analyse. But tolerance is not authorisation, and the asymmetry matters: the subscriber carries the revocation duty under TCU §5.2.12 if a PIN leaves their possession, so under the contract it is the user, not the agent vendor, who carries the risk.

Third, none of this is legal advice, and SK’s terms are amended from time to time. Anyone building an agent against Smart-ID should check the current terms with SK or their relying party rather than take this reading as the final word. The reading here reflects the documents as published on 8 September 2026; on 4 October 2026 SK had not published a newer version of the terms.