DESAmedia ·

The short answer

If your customers, partners or staff still print, sign and scan contracts, or log in to your system with nothing more than a password, adding Smart-ID, Mobile-ID and e-signatures is one of the quickest improvements to pay for itself. The technical side is not hard: Smart-ID and e-signature providers offer REST APIs and free test environments. The difficult part is everything around the login itself. You need to decide which signature level you need, which format the signed document is stored in, how it flows back into your CRM or ERP, and what happens when the provider changes its API.

There is one more question on the table at the end of this year. Under the EU's revised digital identity regulation (eIDAS 2), every EU country has to offer its residents a European Digital Identity Wallet (EUDI Wallet) by the end of 2026, and some private companies, such as banks, energy suppliers and telecoms operators, will have to accept it by 24 December 2027 at the latest. This guide looks at all of it from the buyer's side, with a focus on Lithuania. We checked the sources on 10 November 2026. It is practical guidance, not legal advice.

Two different jobs: logging in and signing documents

When people say "Smart-ID integration", they often mean two separate processes that differ in cost and complexity.

Identity verification (login). The user enters their personal code or scans a QR code, confirms with a PIN on their phone, and your system receives a verified name, surname and personal code. It replaces the password and tells you reliably who is logged in. This suits customer self-service, staff portals and application systems.

Document signing. The user reviews a specific document, say a contract in PDF, and signs it. The result is a signed file that can still be verified years later. Here you have to think about signature level, file format, storage and who signs on behalf of a company.

Many projects start with login and add signing later. That is fine, but plan the architecture for both from day one, because the same user data and usually the same provider serve both.

Which level of e-signature do you need?

The EU eIDAS Regulation (No 910/2014) defines three levels:

Level What it is Typically enough for
Simple electronic signature Any electronic confirmation, such as a ticked box or a clicked button Internal approvals, accepting terms
Advanced electronic signature Uniquely linked to the signer and shows whether the document changed after signing Some B2B documents where both sides agree in advance
Qualified electronic signature (QES) An advanced signature created with a qualified device and a qualified certificate Contracts where you want the weight of a handwritten signature, documents for public bodies

The key rule: under Article 25 of eIDAS, a qualified electronic signature has the same legal effect as a handwritten one. Lower-level signatures are not "invalid", but in a dispute you would have to prove their evidential value.

Smart-ID states that its signatures can be AdES, QC or QES level and that it holds a qualified signature creation device (QSCD) certification under eIDAS. In practice, anyone with a full Smart-ID account can sign with a qualified signature without a card reader. One catch: Smart-ID also has "Basic" accounts, which only reach the advanced (ADVANCED) level. Your system should check the level of the certificate a document was signed with, not just the fact that it was signed.

Three ways to integrate

Route When it fits What to consider
Directly with the Smart-ID API (SK ID Solutions) You only need Smart-ID, volumes are high, you want fewer intermediaries A contract with SK, your own signature formatting and validation, keeping up with API versions
Through a signing service provider (e.g. Dokobit or others) You need Smart-ID, Mobile-ID, ID cards and other countries' tools, plus ready-made document formats A fee per transaction or plan, and one more supplier to depend on
Through Lithuania's e-government gateway (VIISP) You are a public body and need trusted login for e-services Access is granted to institutions on request, and it covers login, not document signing

Direct Smart-ID integration. SK ID Solutions offers a free test environment and test accounts before you sign anything. To go live you need a service agreement, a public service name (which users see in the Smart-ID app) and a unique relying party identifier (RPUUID). Pricing depends on the number of successful transactions per month, with no setup fee. This is a good choice when you only need login or when signing volumes are high.

Through an intermediary. Providers such as Dokobit offer identity verification and signing with Smart-ID, Mobile-ID, ID cards and Latvian, Estonian and some other countries' tools through a single API, and they create and validate signed documents for you. You don't have to handle signature formats yourself, which saves a lot of development time. You pay per use according to the provider's price list, so estimate your yearly transaction volume before you choose.

For the public sector. Institutions can use the identity service of Lithuania's e-government gateway. It authenticates the person and passes on their data, or the data of the person or company they represent, based on state registers including the Register of Legal Entities and the Register of Powers of Attorney. That is especially useful when you need to know not only who logged in but also which company they act for. Document signing in such systems usually has to be solved separately.

Document formats and storage

A signed document is not just a PDF with a picture of a signature. In Lithuania you will mostly meet three options:

  • PDF with an embedded signature (PAdES). Easiest for the recipient: it opens in any PDF reader and the signature can be checked. It works for most business contracts.
  • ASiC-E container. One or more files and their signatures packed together. Handy when several attachments are signed at once.
  • ADOC. A Lithuanian e-document specification approved by the Chief Archivist, widely used in the public sector.

One thing changed this year for ADOC. On 6 January 2026, the Office of the Chief Archivist of Lithuania rebuilt its online ADOC signing and validation tool. It no longer lets users add another qualified signature to an existing ADOC document or create registration, endorsement or approval signatures. The Office recommends that legal entities without their own infrastructure use other providers' solutions. If your process relied on that free tool, now is a good time to move it into your own system or a provider's service.

Don't forget storage either. The Office reminds organisations that under Lithuania's Law on Documents and Archives, a legal entity must keep its electronic documents authentic, reliable and accessible for the whole retention period. So your system should store the original signed file, its validation result and a link to the business record (contract, order, application), not just a "signed" flag.

Smart-ID API v3: what existing integrations need to know

In summer 2025, SK ID Solutions launched Smart-ID+ with Relying Party API v3. The main changes:

  • New login flows without typing a personal code: a QR code when the user is on a computer, and Web2App or App2App when they are on the same phone. This is much smoother on mobile.
  • Security improvements: every request now needs a random challenge generated by your system (rpChallenge) to prevent replay attacks, and RSA signatures now use RSASSA-PSS only.
  • Older versions keep working. The official FAQ says API v1 and v2 will remain working, while encouraging providers to start moving to the new flows.

So there is no rush, but it is worth planning the move, especially if many of your users log in on their phones. One more practical reminder: on 6 October 2026, SK replaced the TLS certificate of the Smart-ID API, and service providers who had not added the new certificate in time could not use Smart-ID. If your system pins certificates, your maintenance plan should say clearly who watches for such notices and who makes the change.

The EUDI Wallet: what the 2026 and 2027 dates mean

Regulation (EU) 2024/1183 (eIDAS 2) requires every member state to provide at least one European Digital Identity Wallet. Counting from the date its implementing acts came into force (24 December 2024), that has to happen by the end of 2026. A wallet on the phone will let people log in, share verified data such as age, address or a diploma, and sign with a qualified signature.

In Lithuania, according to public reports, the work is under way: the State Digital Solutions Agency has procured a wallet test environment, and the Seimas Economic Committee describes the country as being in an "active implementation phase". When we checked, we found no official date for when a Lithuanian wallet will be available to all residents.

What this means for businesses:

  • Mandatory acceptance applies to some, not all. Under Article 5f, private organisations that law or contract requires to use strong user authentication (the regulation names transport, energy, banking, financial services, health, postal services, education, telecoms and other areas) must accept the wallet at the user's request no later than 36 months after the implementing acts came into force. That works out to 24 December 2027.
  • Micro and small enterprises are exempt. Medium-sized and large companies are not.
  • The wallet is an extra option, not a replacement. Using it is voluntary for citizens, so Smart-ID and other tools are not going away.
  • You will need to register. A company that wants to request wallet data has to register as a relying party in its own country and state which data it will ask for and why.

The practical takeaway: if you are building or upgrading a system now, keep identity verification in a separate module that can work with several providers (Smart-ID, Mobile-ID, ID card and later the EUDI Wallet). Then you can add a new method without reworking the whole system.

Example: signing a contract without paper

This example is fictional. The company "Pine Equipment" does not exist.

Pine Equipment rents out construction machinery. Every rental starts with a contract that a sales manager prepares in a Word template and emails to the customer, who prints it, signs it, scans it and sends it back. Quite often the machine has already left the yard before the signed contract arrives.

In the new process:

  1. The manager marks the order "ready for contract" in the CRM. The system generates a contract PDF from a template with the customer and machine details.
  2. The customer gets a link, logs in to the self-service portal with Smart-ID or Mobile-ID and reviews the contract.
  3. The customer signs with a qualified signature. The system checks the signature level and that the signer is the company representative whose personal code matches the contact in the CRM.
  4. Pine Equipment's managing director then countersigns. The signed PDF is saved in document storage together with its validation report.
  5. The order status in the CRM changes to "signed" automatically, the warehouse gets the go-ahead to release the machine, and invoice details go to the accounting system.

Notice that the signature itself is only one of five steps. Most of the value comes from the document being linked to the order and to the processes around it.

What to put in your technical specification

Answer these questions before you talk to developers. They will save a lot of back and forth.

  • Who logs in and who signs: customers, staff, partners, foreign users? Do you need Latvian and Estonian tools?
  • Which tools: Smart-ID, Mobile-ID, ID card, and later the EUDI Wallet? Do you need login, signing, or both?
  • Which signature level for each document type, and should the system reject lower-level signatures?
  • Who signs for the company, and how is the right to represent it checked (CRM data, powers of attorney, the Register of Legal Entities)?
  • Format: PDF (PAdES), ASiC-E or ADOC? Does one document need several signatures, and in what order?
  • Where signed files are stored, for how long, and who can access them.
  • Which events flow to other systems: CRM, ERP, accounting, email.
  • Who maintains the integration: API version upgrades, certificate changes, following provider notices.
  • How many transactions a month you expect now and in a year. That decides whether a direct connection or an intermediary makes more sense.

Common mistakes

  • Keeping a "signed" flag instead of the file itself. In a dispute you will need the original signed document, not a database record.
  • Not checking the certificate level. A Basic account signature is not qualified, even though the process looks the same to the user.
  • Not linking the person to the company. Smart-ID confirms who the person is, not that they may sign for a company.
  • Wiring the provider's API straight into business logic. When the API version changes or a new tool appears, half the system has to be rewritten.
  • No maintenance plan. Certificate and API changes happen regularly, and a broken signing step means stalled sales.

FAQ

Can Smart-ID be added to an existing system without rebuilding it?

Yes. Usually a separate login and signing module is added that talks to the Smart-ID or intermediary API, and the existing system receives a verified user or a signed file. It is a typical integration project.

Is a contract signed electronically as valid as a paper one?

Under Article 25 of eIDAS, a qualified electronic signature has the same legal effect as a handwritten signature. For specific contract types where the law requires a special form, such as notarisation, check with a lawyer.

Does my company have to accept the EUDI Wallet?

Only if you are a medium-sized or large company and law or contract requires you to use strong user authentication, for example in finance, energy or telecoms. In that case you must accept the wallet at the user's request no later than 24 December 2027. For everyone else it is an optional extra.

How much does Smart-ID cost?

Directly with SK ID Solutions, you pay based on the number of successful transactions per month, with no setup fee. Intermediaries have their own price lists. Building the integration is a separate cost that depends on whether you need only login or also document signing with links to your CRM or ERP. We cover the cost drivers in our article on what custom software development costs.

Where to start

Start with the one process that creates the most paper or waiting today, usually customer contracts or staff documents. Write down who signs, which signature level is needed and where the document has to end up after signing. That is enough for a first conversation with developers, and our technical specification guide will help you turn it into a full brief.

DESAmedia builds these solutions in practice. In our grant assessment and contract e-signing platform, for example, contracts are generated from templates and signed with Smart-ID, and every action is recorded in an audit log. We can connect Smart-ID, Mobile-ID and e-signatures to your CRM, ERP or customer self-service portal through our integration and automation work, and we help institutions through our public sector services. If you are choosing who to trust with such a project, our 12 questions to ask a software partner will help too. To talk it through, get in touch via our contact page.

Sources