Digital signing software requirements under Decree 23/2025: Article 17 and the April 2027 deadline

Decree 23/2025/ND-CP on electronic signatures and trust services was issued on 21 February 2025 and takes effect on 10 April 2025. One provision that has drawn less attention but lands squarely on IT departments: for the first time, a decree spells out mandatory functional requirements for digital signing software and signature-verification software. Systems that already integrate signing have two years to close the gap.

This article does not cover approval workflows or records management — that ground is covered in digital signing in the paperless office under Decree 23/2025. What follows is the technical side: what the software must do, who is accountable, and by when.

First, check whether the decree applies to you

Article 1 of Decree 23/2025/ND-CP explicitly excludes specialised digital signatures for public duties from its scope. That category sits under Decree 68/2024/ND-CP and is administered by the Government Cipher Committee, with its own certificate hierarchy and standards.

This is the most common point of confusion in the public sector. Many agencies run both: specialised public-duty signatures for administrative documents moving across the national document exchange, and public digital signatures for contracts, invoices, and dealings with businesses. Any compliance review has to separate the flows first — which ones fall under Decree 23/2025, which under Decree 68/2024. Applying the wrong framework means doing the work twice.

Decree 23/2025 also repeals Decree 130/2018/ND-CP and Decree 48/2024/ND-CP (Article 46). If your technical documentation, contracts, or tender files still cite those two, they lapse on 10 April 2025.

Article 17: five mandatory functions for signing software

Article 17 requires digital signing software to provide five groups of functions:

• Authenticating the signer and performing the signature. The software must establish who is signing before it creates the signature.
• Checking the validity of the signing certificate, with a connection to the public digital signature certification services gateway. Technically this is the heaviest requirement; more on it below.
• Storing and destroying the accompanying information attached to the signed data message.
• Adding or removing certificates from the set the software accepts.
• Reporting the outcome of each signing attempt, successful or failed.

It reads simply enough, but in practice many in-house systems implement only the first and the fifth. Certificate validity checking is usually reduced to "is it still within its validity period" — when validity actually depends on revocation status, the chain of trust up to the national root, and usage constraints. Public digital signature certificates run for a maximum of three years under Article 7, but can be revoked at any point within those three years.

What signature-verification software means here

The decree treats this as a separate category. Signature-verification software verifies a signature already present on a data message; it does not create signatures. In practice this is the "check a signed document" function in a public service portal, an inbound-correspondence reader, or a contract reconciliation tool.

Article 17(3) requires four functions for this category: checking the validity of the digital signature on the data message; storing and destroying information accompanying the signed data message; adding and removing the certificates issued by certificate-issuing bodies; and reporting, in words or symbols, whether the signature is valid or not. Note that the requirement to connect to the public certification services gateway sits in Article 17(2) — it applies to signing software, not verification software.

It comes with a notable prohibition: technical barriers must not be used to restrict the checking of digital signature validity. Operationally, a recipient must be able to verify a signature without being forced into one vendor's proprietary client, without format lock-in, and without paying for verification. If your system produces signed documents that only one specific plugin can open, that is a defect to fix.

The public certification services gateway

The requirement to connect to the public digital signature certification services gateway changes the architecture of many systems. The traditional approach was for each application to keep its own list of CA root certificates, validate chains locally, and update the list by hand whenever a new CA appeared or a root changed. That approach always lags reality and cannot see revocation status in near real time.

The gateway is the central point through which software queries the validity of certificates issued by licensed public certification service providers. The Ministry of Information and Communications is the authority guiding implementation. On the provider side, Article 47(4) gives public certification service providers already in operation two years to upgrade their technical systems and staffing.

On your side, the planning work involves opening outbound connectivity from the network segment hosting the signing service, deciding what happens when the gateway does not respond (treating a signature as valid by default when you cannot check it is not an acceptable answer), and logging every check so it can be reconciled later.

The 10 April 2027 deadline, and who owns it

Article 47(6) requires application software that integrates digital signing or signature verification to be reviewed and upgraded to meet Article 17 within two years from the effective date. The decree takes effect on 10 April 2025, so the deadline is 10 April 2027.

Article 47(7) is specific that the obligation rests with the owner of the information system — the organisation operating it, not the software vendor. That matters in contract discussions. If your signing system was built by an external party and the warranty has expired, the upgrade cost is yours unless the contract contains a regulatory-compliance clause.

Two years sounds generous but is not. For a running system the sequence is usually: assess the current state, engage the vendor, wait for a patch or a new release, test, secure budget if there is a cost, then deploy. Public sector budget cycles run annually, which means the real decision point falls well before the legal deadline.

An easy misreading about specialised electronic signatures

The Law on Electronic Transactions 20/2023/QH15 divides electronic signatures by scope of use into three categories in Article 22(1): specialised electronic signatures, public digital signatures, and specialised digital signatures for public duties. Article 23(2) of the Law on Electronic Transactions 2023 gives safety-assured specialised electronic signatures and digital signatures legal effect equivalent to a handwritten signature.

Article 9 of Decree 23/2025 adds that a safety-assured specialised electronic signature, where it is backed by a certificate issued by the creating agency or organisation itself, is considered to meet the technical requirements in Article 22(2) of the Law. Its permitted scope covers internal use; use under sector-specific or affiliation charters; and representing the organisation itself in transactions with other organisations and individuals.

Here is the trap: "meets the technical requirements" is not the same as "recognised as a safety-assured specialised electronic signature". That designation still requires certification by the competent state authority under Article 25(2) of the Law. And under Article 25(3), registration is mandatory when the signature is used in transactions with other organisations and individuals, or when the organisation seeks that recognition.

The practical reading: issuing your own internal certificates is legitimate and cost-effective for in-house approval flows. But if you intend to use that signature externally, complete the certification procedure first. Do not assume self-issuance alone carries full legal weight.

A review checklist for system owners

Work you can start now, with no budget approval:

• List every point where signing or signature verification happens: eOffice, ERP, public service portal, accounting software, contract signing tools, and any small in-house utilities.
• For each point, identify which signature type is in use: public, internal specialised, or specialised for public duties. The third is governed separately by Decree 68/2024.
• Map each piece of software against the five Article 17 functions. Note which are missing and which exist but are incomplete.
• Test verification for real: sign with a revoked certificate and see whether the system catches it. Many only check the expiry date.
• Export a signed document and try to open and verify it with a third-party tool. If that fails, you have a technical barrier to remove.
• Check the logs: is every signing and every verification recorded with timestamp, subject, and result.

Questions to put to your software vendor, in writing:

• Does the current release meet Article 17 of Decree 23/2025 in full, and if not, which functions are missing.
• What is the roadmap and target date for a fully compliant release.
• How does the product connect to the public certification services gateway, and what connectivity must we open.
• Is the upgrade covered by the existing maintenance contract or billed separately, and at what price.
• If the system runs on-premise with no internet egress, what is the proposed approach for certificate validity checking.

That last question is usually the sticking point for systems in closed internal networks. Settle it early, because it touches network security policy, not just software.

Integrating signing into in-house software without rework

If you are about to integrate signing into an in-house application, a few architectural choices make the next round of upgrades much cheaper.

Centralise signing and verification into one shared service rather than having each application call its own library. When rules change, there is one place to change. It is also the only practical way to get a single, organisation-wide signing audit trail.

Keep certificate validity checking as a separate component so the lookup source can change without touching business applications. And store the full set of accompanying signature information from day one — backfilling it for already-signed documents is close to impossible.

Tetra eOffice is built along those lines: signing is a service within the system, running on your own infrastructure, working with both public CA certificates and internally issued ones.

Conclusion

Article 17 of Decree 23/2025 turns what used to be good practice into a hard requirement, and Article 47(6) puts a 10 April 2027 deadline on systems already in production. The obligation sits with the information system owner and cannot be pushed onto the vendor.

The first step costs nothing: inventory every signing touchpoint, map it against the five functions, and send the vendor questions in writing. Only with that picture can you size the budget and the schedule.

If you need a review of an existing signing system, or want to discuss integration options for an on-premise deployment, book a consultation with the Tetra team.

Note: this article is for reference. When implementing, check directly against the current legal texts and guidance from the competent authority.