What we can tell you, and how we know it.

The assurance level of an identity provider is the level the operator declares from the provider’s documentation, with a recorded reason; it is not measured by us. It is always shown together with the environment, for example “Substantial (declared) · test environment”. A test provider is never offered in a production installation, and an act signed with a test identity carries “test identity, no legal effect”. This installation is a test environment, so test providers can be offered here; in production they would not be.

Conditions and how we know →

PDF signatures are produced as PAdES, and the product reaches the baseline levels B-B, B-T, B-LT and B-LTA as the timestamp authority and the revocation services allow. An independent validator confirmed B-LTA on a measured run.

Condition: Without a timestamp authority a document stays at B-B; with one but without revocation answers, at B-T. B-LT and B-LTA need OCSP or CRL to answer. It is measured on three signatures of a demonstration run, not on every document: each document carries the level it reached that day, and a validator reports it.

Conditions and how we know →

The European Commission’s open-source validator, DSS 6.5, checks the structure of the signed PDFs the product produces, on every change that touches what it measures and every night.

Condition: It runs against our laboratory kit, never against customer documents. Passing DSS’s structure check is not a statement about anyone’s legal framework, and the PAdES level DSS reports does not imply a qualified status.

Conditions and how we know →

The time on a signature or on a stand-alone sealed file comes from a timestamp authority speaking RFC 3161, not from our clock. The authority is the one this installation is configured to use.

Condition: Only if a timestamp authority is enabled and answering. The product checks that the timestamp covers the bytes it should; whether the authority’s own certificate chain is trusted is a separate question that was not demonstrated in our measured run.

Conditions and how we know →

A signer can sign with their own certificate, held at a trust service provider that speaks the CSC API v2. The key stays at the provider and the signer authorises each signature there; the platform never holds it.

Condition: We are a client only: the installation calls the provider’s CSC service, and does not offer a CSC signing server to other systems. The operator configures each provider; the flow is exercised end to end against a CSC simulator in our test suite.

Conditions and how we know →

The product connects to Entrust RSE through its native signing API, its document-signing API and its CSC v2 surface, and reads the signer’s identity through its OpenID Connect API. According to the vendor’s own documentation, that engine keeps the signer’s key in the provider’s HSM and, with its sole-control component on a certified HSM, lets the signer control the use of the key at the level the European standard EN 419 241-2 calls sole control level 2. What reaches us is a signature value over a hash: the document never leaves the installation, and how the signer authenticated is written to the evidence. Providers are configuration: which one an installation uses is the operator’s choice.

Condition: The standing of the device and of the certificate belongs to the provider and to the vendor, not to us: we do not claim a qualified status for any signature the product produces. Which interfaces a given provider offers, which HSM it runs and what its licence covers is the provider’s declaration, read from the vendor’s documentation and not measured by us against a production engine. Our measured runs are against a simulator and against a pre-production environment.

Conditions and how we know →

The three levels, low, substantial and high, are read from the answer of the identity provider and compared with the level the sender asked of each signer. If the proof falls short, the signature is refused and nothing is signed. The evidence says the level asked and the level proven.

Condition: The level is what the identity provider declares, never more than the ceiling the operator set for it. It binds to whoever opens the link and proves their own identity at that level; it does not prove they are the person the invitation was addressed to.

Conditions and how we know →

We are not a trust service provider; we use them. We do not claim that any signature this product produces is a qualified electronic signature, and we never present it as ours. The certificate and its standing belong to the provider the installation is connected to; the product shows what a certificate declares about itself and says plainly that reading it is not validating it.

Condition: Always: it is what we are, not a temporary limit.

Conditions and how we know →

For each signature the product reads the certificate inside the PDF: validity dates, key usage, the policy it was issued under and its qualification statements, and shows them as declared by the certificate. A self-signed certificate is shown as such.

Condition: A declaration is not a verdict: a certificate saying it is qualified does not make it so, and the product does not decide that. Trust in the chain, revocation and trusted lists are other checks.

Conditions and how we know →

We do not assume a timestamp is qualified. At the moment it is made, the evidence record notes whether the authority was backed by a provider listed for the document’s country, and keeps that answer as it was then. A stand-alone authority is never recorded as qualified.

Condition: It depends on the provider data configured for the installation. Authorities flagged as test authorities are shown as such.

Conditions and how we know →

Uruguay’s electronic certification unit publishes a machine-readable trusted list that carries the national root under which its accredited certification providers issue. The installation downloads that list, verifies its signature against a signer certificate the operator configured, respects its expiry, refuses an older version than one already seen, and uses it to answer one question about each signature: does this certificate chain end in a service the list recognises? When it does, the certificate was issued under a provider the unit accredits, and the product writes that answer, as it was that day, into the evidence. The same list feeds the validation service where an installation runs it.

Condition: The product reads the list; it does not grant the accreditation and it does not decide what a signature is worth anywhere. Without the operator’s setup the list is neither downloaded nor believed, and the answer is “unknown”. The list signer’s fingerprint is taken from the list once and must be confirmed with the issuer through another channel before an installation relies on it in production.

Conditions and how we know →

An installation can run DSS-FS, a validation service built on the European library that lives in the installation’s private network. With it, a signed PDF is validated the way that library validates: certificate path, revocation by OCSP or CRL, timestamps, and the signature’s conformance to its declared level, with a report. The same service checks PDF/A conformance with veraPDF and reports it as information, never as a signature failure. Its trust comes from signed trusted lists: the European list of lists and every national list it points to, the Mercosur list of lists through which Paraguay’s enters, and Uruguay’s list. Argentina’s list is one more line of the same set: it is loaded on its own, with its signer fixed from a file. A list that is expired or whose signature does not verify is rejected, never accepted on faith.

Condition: Only where the installation runs that service. It needs outbound access to the list publishers and to the revocation servers each certificate names; the product’s own checker keeps running without it. A report is a reading at a date, with the material available that day, and long-term validity depends on that material being kept. A list signer taken from a list once must be confirmed with its issuer through another channel before an installation relies on it in production. At the last measurement one national list failed its own signature check and was rejected, as designed.

Conditions and how we know →

Only PDF is signed. A word-processor, spreadsheet, presentation or image file can enter converted to a PDF/A-2b copy, on request or by account policy; the conversion is written to the evidence and the original is kept as evidence.

Condition: The copy declares PDF/A-2b. A veraPDF check confirmed it on a test document in our CI, not on every customer copy. Needs the conversion tools in the installation; without them the file is refused at the door.

Conditions and how we know →

Every card on this page says how it was measured: a test in continuous integration, a laboratory run against an independent validator, a reading of the code. None of it is an audit or a certification by a third party, and we do not present it as one. An auditor who wants to repeat a measurement can ask for the laboratory kit and the commands behind each figure.

Condition: Always. Where a figure comes from a single run, the card says so.

Conditions and how we know →

Write to no-reply+security@interfase.global, and please do not report a security problem through any public channel, and do not include real personal data, real documents or real credentials in the report. In scope: the product and the container image built from it. Out of scope: third-party services we integrate with, denial of service by volume, social engineering and findings that need physical access to a device.

Condition: Only the main branch is maintained; a fix reaches a running installation when that installation is redeployed. The response targets are a proposal pending management approval, not a commitment: acknowledgement within 3 business days, a verdict on whether it is a vulnerability within 10 business days, and a proposed 7 days (critical), 30 days (high) and 90 days (medium) for a fix or mitigation.

Conditions and how we know →

Dependency updates are proposed weekly, for packages and for the build pipeline’s own actions, and each one goes through review like any other change; none is merged automatically. Every pull request, and a weekly run, is checked with npm audit, and every pull request is scanned for committed secrets, the weekly run over the whole history. Installs use the lock file exactly, and the container’s base image is pinned by digest.

Condition: The npm audit check reports; it does not yet block a merge, because advisories with no published fix exist in the tree. The secret scan does turn the pull request red.

Conditions and how we know →

The signer’s own key never reaches the platform when a remote provider holds it: with a CSC provider or a remote signing engine the key stays in the provider’s HSM and the signer authorises each signature there. The platform’s own keys, the ones behind the platform seal and an organization seal, can live in five places: a file held by the platform, which is the default; a software token; a cloud HSM; a network HSM; or a remote signing engine. Which of them is in place, which has been measured and which is only allowed by the product is written place by place in the auditor guide.

Condition: So we do not say that we never hold private keys: with the default engine we hold the platform’s own, in a file. Where a custody service holds the key, it is refused if the token declares it extractable, the PIN never appears in a log, and every signature is verified against the certificate before it leaves. Which place an installation uses is the operator’s choice and responsibility; the custody service must stay in a private network.

Conditions and how we know →

When the product fetches something from an address someone typed in, such as a document by URL, a provider logo or a certificate revocation list, it checks on the connection itself, and again on every redirect, that the destination is public. Internal addresses, loopback and cloud metadata addresses are refused, and the response is cut off at a size limit while it is being read. Operator-configured connectors may reach a private data centre network, but never loopback or link-local addresses.

Condition: Webhooks and the event exporter keep a check made before the request, which leaves a narrow DNS window that is documented in the code.

Conditions and how we know →

The typefaces ship with the product, under their open licences, and the content security policy does not authorise any third party for styles or fonts. A closed network sees the same page as an open one.

Condition: Other browser-side requests exist: the anti-bot challenge, if the operator switches it on, loads from its provider; provider logos pasted as a URL are fetched by the browser from that address; and mobile push goes through the browser vendor’s service.

Conditions and how we know →

The product gives cryptography, a timestamp when configured, and a record of what happened. Whether a signature is accepted for a given document in a given country depends on that country’s framework, the type of document and the certificates used. We make no statement about it for any country, and local law has to be reviewed by a local lawyer.

Condition: Check the intended jurisdictions before relying on a signed document, and test the outcome in the PDF reader your counterparts will use.

Conditions and how we know →

Every evidence event is linked to the previous one by hash, so altering one event without recalculating the rest of the chain is detected. The delivery package exports those hashes, so a recipient who keeps a package holds a copy to compare against.

Condition: It holds within one installation and against someone who cannot rewrite the whole chain. The platform keeps no external anchor of the hashes, so we do not say the evidence is unalterable or immutable: what exists is detection of partial alteration.

Conditions and how we know →

Each digital signature covers the state of the PDF at the moment of signing, and a later change does not alter what it covered. Permitted later changes can coexist with valid earlier signatures; the revision history in the reader shows what changed.

Condition: We do not offer a hard lock, and we do not say a signed document cannot be modified. In a desktop PDF reader, on our laboratory files, a lock on all fields did not prevent later signatures. We also do not certify documents (DocMDP) today.

Conditions and how we know →

A timestamp from an external authority gives proof of time that does not depend on our clock. A file sealed on its own, with no signature, proves that this file existed at that time. It does not say who made it, that anyone agrees with it, or that it is authentic.

Condition: Only if the installation has a timestamp authority enabled and available; it is not automatic. When the authority does not answer, the evidence record notes why there is no timestamp instead of staying silent.

Conditions and how we know →

The product’s checker reads the structure of a signed PDF, whether each signature matches its certificate, and timestamps, including a document signed by another product. It says what it did not look at.

Condition: A validator saying “valid” is not a statement that nobody tampered with the file: in our measurements the European validator, under its default policy, passed a file in which a locked field had been rewritten. Results also depend on the reader, the trust configuration and the revocation material available when you check, and long-term validation depends on that material.

Conditions and how we know →

The same product runs three ways: in a shared cloud (SaaS), as a dedicated instance in the cloud, or on the customer’s own infrastructure. Each installation declares which one it is, who operates it, where it is hosted and whether it is a sandbox or production; those declared facts are shown further down on this tab.

Condition: A sandbox is a demonstration environment, not production, and carries no availability commitment. A dedicated cloud is the same image running as another instance. We publish no service level.

Conditions and how we know →

Signing, timestamping, storing and proving can run entirely inside your network. What leaves is optional and can be switched off: the anti-bot challenge and mobile push notifications with an environment variable, SMS and WhatsApp by leaving the messaging provider inactive in the operator’s configuration, and the payment gateway by taking it out of the contract’s scope. Mail, the identity provider, the timestamp authority and the remote-signing provider go wherever you point them, including a service of your own. Every installation can list its own outbound needs from the database.

Condition: Two things cannot be avoided if you want the function: the revocation servers named by each certificate (without reaching them, documents stay at B-T and do not reach B-LT), and the eIDAS identification node, which a member state operates. Mobile push goes through the browser vendors’ own services. Inventory measured on the code on 12 September 2026; at that measurement we found no analytics, error reporting or update check.

Conditions and how we know →

The optional DSS-FS validation service is not published: it lives in the installation’s private network, needs a long random service token to start, runs as an unprivileged user with a read-only file system, and is only allowed to reach public destinations for the revocation and certificate lookups that a document being validated asks for.

Condition: Only where the installation runs it. In the measured container the memory is capped, and so is the number of parallel validations; the one that does not fit is refused at once, never queued. The exact limits are in the auditor guide.

Conditions and how we know →

A rehearsed backup and restore, with the recovery point and recovery time stated, is offered on request. It is not part of the product today.

Condition: Not exercised in this environment yet. What exists today is a documented procedure, not a rehearsed one, and no recovery point or recovery time is promised.

Conditions and how we know →

Whether a person can identify themselves with a digital identity wallet depends on the installation: it is offered only when the installation has a wallet service set up and running. In this installation it is available.

Condition: This shows the state of this installation now, not a promise about any other one.

Conditions and how we know →