eNoVA, XML Signatures, and QES for Authorities: What Digital Real Estate Execution Requires

The digital execution of real estate transactions is becoming increasingly concrete for many authorities. What was previously handled in most cases on paper, by post, or through manual coordination is now set to be digitized. Particularly relevant is the exchange between notaries and public authorities.

The eNoVA Act, announced in June 2026, aims to digitize the exchange between administrations and notaries. For approval authorities, building administrations, land registry offices, and legal departments, this means: Documents relevant to the land register, such as certificates, approvals, and declarations, must not only be created digitally but also signed, transmitted, and stored in a way that ensures their origin, integrity, and usability in the process remain traceable.

In many cases, simply saving a paper document as a PDF is not sufficient. In digital real estate execution, structured data, XJustiz-XML, qualified electronic signatures, and certificates with organizational details play a crucial role.

For authorities, it is therefore important to clarify at an early stage:

• which individuals are authorized to sign
• which organizational information should be visible in certificates
• which specialist procedures need to be integrated
• how XML datasets can be integrated into digital workflows

eNoVA may affect all documents and data required in connection with real estate transactions. Which specific documents and procedural steps are affected in individual cases depends on the respective jurisdiction, the specialist procedure, and the legal requirements of the specific administrative area.
For eNoVA authorities, this results in several fields of action:

• electronic receipt and processing of requests from notaries
• digital creation of land-register-relevant declarations
• use of structured data formats, especially XML or XJustiz
• secure transmission via suitable communication channels
• use of qualified electronic signatures or appropriate certificate proofs
• organizational regulations for signature authorizations, deputization, and record-keeping

 
Thus, eNoVA is not only an IT project but also an organizational and compliance issue for authorities.

§ 137 Para. 2 GBO contains relevant provisions for electronic documents in land register proceedings. This paragraph is particularly important for authorities because electronic documents in land register proceedings must be traceably assignable to a person and an authority. In many cases, the qualified electronic signature plays a central role. However, the specific form required in each procedure should always be reviewed from a specialist and legal perspective.

A qualified electronic signature (QES) is the highest level of trust for electronic signatures within the European legal framework. In the context of public authorities, the QES primarily serves to assign an electronic declaration to a natural person. Unlike a purely organization-related seal, the QES makes it clear which specific person has signed the content.
The QES is used when a declaration should not only come from “the authority” but must be assigned to a responsible officer, a department head, an authorized signatory, or another natural person.

A qualified signature certificate can additionally include organizational details. Possible entries include:

• Name of the organization: “City of Sampletown”
• Organizational unit: “Legal Department”
• Organizational unit: “Building Authority”
• Organizational unit: “Land Registry Office”
• District, municipality, office, or responsible administrative unit

 
Such details must be verified before the certificate is issued. The authority affiliation of the signing person can typically be confirmed by a person authorized to represent the authority or through a comparable suitable proof. The exact design depends on the trust service provider, the type of certificate, and the respective verification processes.

Depending on the requirements, administrative staff should define whether a QES, a qualified electronic seal, or a qualified attribute certificate is needed. These instruments serve different functions and should not be equated.
As mentioned above, a QES proves the declaration of intent or knowledge of a natural person.

A qualified electronic seal, on the other hand, proves the origin of an electronic document or dataset from an organization. It confirms organizational origin and integrity.

Technically, both QES and seals can be implemented via API, as a cloud-based solution, or with a local token.

A qualified attribute certificate can prove additional properties, roles, or functions of a person. This can include, for example, an official function, authority affiliation, or a specific role, provided these attributes are reliably verified and can be mapped on the certificate side.

This results in a practical checklist:

• Should a natural person sign a declaration?
  • > QES
• Should the origin from an authority or organization be proven?
  • > Qualified electronic seal
• Should a specific role, function, or affiliation also be proven?
  • > Qualified attribute certificate or certificate with verified organizational details
• Do structured data need to be secured in a machine-readable way?
  • > XML signature, if necessary with qualified signature level

Which option is required or sufficient cannot be answered in general terms. Authorities should review this separately for each procedure.

The electronic exchange between notaries, authorities, courts, and other bodies increasingly involves not only documents but also structured data.
Such structured datasets can be processed, validated, and integrated into specialist procedures automatically. This is precisely where one of the key advantages of digital procedures lies: data no longer needs to be manually re-entered, media disruptions are reduced, and processing workflows can be better automated.

In adjacent judicial and administrative procedures, XML-based standards such as XJustiz already play an important role. Whether and in what form XJustiz will be relevant in the specific eNoVA procedure, however, depends on the legal requirements.

For authorities, therefore, it is not only important to consider how a PDF or document is signed. Equally relevant is whether structured XML datasets can be signed, verified, and archived.

What is an XML Signature?

The W3C standard for XML signatures describes how digital signatures can be embedded in XML structures and linked to XML data or referenced data. An XML signature protects structured data from undetected changes and enables the technical verification of integrity. The XML signature allows the signing of data of any kind, provided it is embedded in an XML document or can be referenced via a URI.

For authorities with established specialist procedures, manually signing individual files is often not sufficiently scalable. If applications, approvals, or declarations are generated directly within a specialist procedure, the signature process should also be seamlessly integrated into this workflow.
A QES via API can play a central role here. The specialist procedure triggers the signature process via an interface, submits the dataset to be signed, and subsequently receives the qualified signed dataset, the signature file, or a suitable signature proof in return. Depending on the technical architecture, this can be implemented for PDF documents, XML datasets, or other signable formats.

A typical process may look as follows:

1. The specialist procedure generates an approval, certificate, or declaration.
2. The relevant content is provided as a PDF, XML, or XJustiz-XML dataset.
3. The signing person is authenticated.
4. The QES is triggered.
5. The signed dataset is returned to the specialist procedure.
6. The result is saved, transmitted, or forwarded to a downstream system.

 
An API integration reduces media disruptions and supports uniform processes. At the same time, authorizations, logging, deputization rules, and error handling must be carefully planned.

Before an authority introduces a QES or XML signature solution, several organizational questions should be clarified. Experience shows that these points are at least as important for successful implementation as the technical integration.
In particular, the following should be reviewed:

• Which specialist areas are affected?
• Which documents or datasets need to be signed?
• Which procedures fall under eNoVA or digital real estate execution?
• How many people should be able to sign with a qualified electronic signature?
• What roles or functions do these people have?
• What annual signature volumes are expected?
• Which organizational details should appear in the qualified signature certificate?
• Who is authorized to confirm authority affiliation or signing authorization?
• What deputization rules apply?
• Which specialist procedures need to be integrated?
• Do XJustiz-XML datasets need to be signed?
• How are signed data archived and verified?
• What requirements exist for logging and traceability?

 
Early communication with notaries and land registry offices should also be considered. Only if data format, signature type, transmission path, and verification mechanism are aligned can digital real estate execution function efficiently.

We support authorities in integrating qualified electronic signatures into digital administrative processes. This includes qualified signature certificates for employees, verified organizational details in the certificate, API-capable signature processes, and the ability to sign not only PDF documents but also XML datasets. This is particularly important for eNoVA scenarios when structured data needs to be secured directly from specialist procedures and further processed.
In summary:

• Provision of qualified electronic signatures
• Qualified signature certificates with verified organizational details
• Representation of organizational units
• Verification of authority affiliation before certificate issuance
• Support for certificate and signature processes for natural persons
• Technical integration of QES processes into specialist procedures
• API-capable signature processes for digital workflows
• Ability to sign XML datasets
• Support for signing structured data, including XJustiz-XML scenarios

 
This addresses not only the classic PDF signature but also the need for XML signatures in structured administrative processes. An important building block for connecting specialist procedures, signature infrastructure, and legally valid electronic communication.

SIGN8 provides technical solutions and qualified trust services but does not replace legal review by the responsible authority.