The useful question is not simply “Can this supplier sign XML?” It is “Can our final IVI file be signed under the required identity and accepted by our receiving service?” Answer that before buying certificates or building a production integration. The document identity, technical signature profile and destination acceptance need to agree.
Sources checked: 16 October 2026. The selection and test steps below are engineering recommendations. Confirm the required signature level and profile with the selected NAP or authority.
What is the difference between a signature and a seal?
A personal electronic signature concerns a natural person; a company electronic seal concerns the origin and integrity of data associated with a legal person. The European Commission’s explanation of electronic seals helps establish that distinction. Do not use the terms as product synonyms.
Also separate the certificate’s trust level from the signature’s technical format. A qualified certificate, a signing device or service, the document signature and the verifier’s result are related, but one does not prove all the others. Record what is actually required rather than copying a supplier’s marketing label into the specification.
Scroll the table horizontally to view all columns.
| Item | Purpose | Question to resolve |
|---|---|---|
| Personal signature or organisational seal | Document identity and integrity | Which identity and trust level does the receiver accept? |
| XML signature profile | How the signature binds to the structured file | Which algorithms, references and packaging are required? |
| TLS or transport certificate | Secure communication with an endpoint | Does the connection require mutual authentication? |
| API token or account permission | Authorisation to use a submission service | Which manufacturer, environment and operations are permitted? |
| Receiving-system response | Evidence of the destination outcome | Was the signed record actually accepted? |
Does every eCoC route impose the same signing requirement?
Regulation (EU) 2024/1061 addresses secure eCoC exchange. Turn the applicable legal and receiving-system requirements into a written contract covering identity, trust level, XML profile, certificate chain, validation and error reporting. Do not assume that a certificate purchased for another business process satisfies that contract.
The VCA security guidance describes its current signature-presence check. A file passing that check is not independent evidence that every cryptographic or certificate-policy requirement has been verified. Keep your own signing validation and destination acceptance as separate records.
How should cloud signing be evaluated?
Cloud signing can avoid local key handling, but the exact transaction needs to be understood. Some services receive a document; others support a defined hash-based operation. Never assume that sending a hash alone will produce the required final XML signature. Establish the payload, signing responsibility and final assembly with the provider.
- Identity: confirm the legal entity or authorised individual represented by the signing credential.
- Payload: document whether the service receives XML, selected signed data or a specifically defined digest.
- Assembly: identify who creates the XML signature structure and binds its references to the final content.
- Authorisation: confirm how unattended or batch operations are approved for your use case.
- Validation: obtain a report for the exact signed output, including certificate context.
- Continuity: test service failure, limits, renewal and credential replacement.
Review access and logging with the people operating the service. A production operator should be able to see why signing failed without receiving private key material. Provider support should receive a redacted technical case rather than unrestricted manufacturer records.
What must remain unchanged after the file is signed?
The submitted file must retain the content and structure covered by its signature. XML reformatting, namespace changes or later field edits can affect verification. Finalise and validate the intended content before signing, then run a check on the signed artefact that will actually be delivered.
Keep a cryptographic digest as an internal identifier for the exact file bytes, alongside the file itself. This supports reconciliation between preparation, signing, archive and delivery. It does not replace signature validation, and a matching local digest does not prove that the authority accepted the record.
A practical acceptance test for your signing service
- Prepare a representative, schema-valid IVI file for the selected destination.
- Complete the configured review and signing authorisation.
- Verify the final signature, certificate chain and required profile using the agreed validation method.
- Submit through the correct test environment and retain the receiving-system result.
- Change a signed value in a separate negative test and confirm that verification detects the change.
- Repeat with an expired or unsuitable test credential where the provider supports this safely.
- Demonstrate recovery from an unavailable signing service without issuing an unsigned production record.
Illustrative example: a manufacturer signs 300 vehicles in a batch. One record fails before signing and another receives no delivery response. The dashboard should distinguish those states. Re-signing or resubmitting every vehicle would conceal the problem and can create unnecessary revisions or duplicates.
Certificate renewal needs an operational owner
Record certificate identity, intended use, expiry, renewal contact and affected integrations. Choose an internal warning period that leaves time for identity checks and a destination test. Test replacement credentials before the old one expires, and preserve the context needed to explain previously signed records.
Ask providers what evidence can be exported when the service contract ends. Retaining only a portal screenshot leaves the manufacturer dependent on a third party to reconstruct its conformity history.
Frequently asked questions
Can the API certificate also sign the eCoC?
Do not assume that. Transport authentication and document signing have different purposes. Check the certificate’s permitted use and the receiver’s explicit document-signing requirements.
Does a PDF signature cover the IVI XML?
A signature applied only to a PDF does not demonstrate that the separate XML data is signed. Validate the artefact required by the receiving service.
Does cloud signing always support unattended production?
No general assumption is safe. Confirm the service’s authorisation model, approved automation, limits and technical interface for the actual manufacturer credential.
What should be kept after a successful test?
Keep the final signed file, validation output, certificate context, destination receipt and the approved test case. These make the result repeatable after changes.
Specify signing before procurement
Combine this checklist with the eCoC software evaluation guide. Discuss your intended NAP or VCA route with Anemon Engineering to define the signing evidence needed for your manufacturer workflow.
Summary
Choose signing around a verified destination contract and a repeatable acceptance test. Retain the exact signed XML, validation evidence and certificate context; manage renewal and authority acceptance as explicit operational tasks.
