The short version

Your document is never uploaded to be signed

Signing happens entirely on your device. There is no upload step, no queue, no worker that opens your file. The one thing that ever leaves is a document you deliberately put in the vault, and that is encrypted on your device before it goes. We do not operate a server that sees document contents.

Your private key never leaves the card

The key lives inside your token or ID card and cannot be exported. The app hands the chip a hash and gets a signature back. The chip signs. We do not have the key.

Your PIN goes to the chip, nowhere else

It is passed straight to the card over the local connection and is never stored, never cached, and never written to a log.

No account is required

The app signs without one. An account exists only to sync your settings, and you can use TapSign forever without creating it.

What happens when you sign

1

The document is hashed

The app computes a SHA-256 digest over the byte ranges of the PDF that the signature will cover. Only this digest is used from here on.
2

The attributes are built

A CMS structure is assembled containing the digest, the signing time, and - where the certificate can be read beforehand - an ESS signing-certificate-v2 attribute that binds the signature to your exact certificate.
3

The chip signs

Those attributes are hashed and handed to the token or card, which performs the signature internally after your PIN unlocks it. The private key never appears in the app.
4

The result is written back

The signature is embedded into the PDF as an incremental update, so any earlier signature stays byte-for-byte intact and independently verifiable.

How Windows and Linux get a newer build

Only the copy you download from this site does this: the Windows zip and the Linux .deb or .rpm. They ask https://tapsign.eu/api/v1/app/update once when they start. The request names the platform, the architecture, the package and the build already on the PC. It does not send a document, a certificate or a PIN. The Microsoft Store build, the Flatpak from our repository and the Apple builds do not make this request. Those copies are updated by the store or repository that installed them. If you tap Later, the prompt waits until the next launch.

https://tapsign.eu/api/v1/app/update

Standards, stated precisely

PAdES / ETSI.CAdES.detached: When the certificate can be read before signing, TapSign emits a CAdES signature with signing-certificate-v2 and the ETSI subfilter. Otherwise it falls back to adbe.pkcs7.detached, which Adobe accepts but which is not PAdES. The app does not claim the stronger label when it has not earned it.
Digest and signature algorithms: SHA-256 throughout. RSA PKCS#1 v1.5 or ECDSA, decided by the key on your card.
Long-term validation: Not implemented yet. TapSign does not currently embed a trusted timestamp or revocation data, so signatures are B-B rather than B-LT or B-LTA. We would rather say so than imply otherwise.
Verification: The app recomputes the digest, checks the CMS signature against the certificate embedded in the file, and reports whether the signature covers the whole document. It does not yet check certificate revocation or build a trust path to an EU trusted list.

Where a signature has legal effect

A PAdES signature is a cryptographic fact: anyone in the world can open the file in Adobe Acrobat and verify it. Legal recognition is a separate question and is national. Inside the EU and EEA, eIDAS gives a qualified signature - one made with a qualified certificate on a token from an accredited provider - the same legal effect as a handwritten signature. Elsewhere, recognition follows local law, which in most countries accepts electronic signatures but on its own terms.

What an account holds

An account exists to sync settings between your devices. It stores your email, optionally your name and phone, which devices you signed in from, and your app preferences: signature style, reason, location, file suffix. It holds no certificates and no keys. There is no password, because we would rather not hold one - you sign in with a one-time code, a passkey, or Sign in with Apple. The one thing an account can hold beyond settings is the vault, which is off unless you switch it on, and which is described in full below.

The vault, and what it still shows us

The vault is optional storage for documents you want on all your devices. It is the only part of TapSign that puts your files on our server, and they arrive as ciphertext we hold no key for. What follows is everything you need to know about it.

Encrypted before it leaves your device

The contents of every file

Each file gets its own 32-byte key and is sealed with AES-256-GCM on your device. That key is stored inside the manifest, which is itself encrypted with your master key. It never sits beside the file it opens, and it never exists on our side in a form we could read.
File names and folder names

There is no column for a name anywhere in our database, so there is nothing for us to promise not to read. Names exist only inside the encrypted manifest.
The whole tree, including favourites

Which folder something sits in, what you renamed, what you marked as a favourite: all of it is one encrypted JSON document per account, replaced whole every time you change something.
The master key itself

Thirty-two random bytes, generated on your device the moment you enable the vault. It reaches us only sealed under a key we do not have, and it never leaves a device in the clear.

Not encrypted, and visible to us

How many objects you have

A count. We can see that an account holds nine encrypted objects, or nine hundred.
The size of each object

To the byte, as stored. A 4 MB file looks like a 4 MB file. Padding would hide this and is not implemented, so if the size of a document would identify it, that is a real leak and this is us telling you about it.
When objects arrived and when the tree changed

Ordinary timestamps. They show when you were working, not what on.
How many ways into the vault the account has

That there is a passkey, a recovery code and two devices, for example. Not the secrets themselves: the kind and the count.
Which account it belongs to

The objects hang off an account identified by an email address. The vault is encrypted storage, not anonymous storage.

That is the complete list, and it is the shape of the tables rather than a policy: an account, a number of bytes, a timestamp. Anything more would mean adding columns, shipping them, and changing the published format.

Free, no ads, no storage limit

The vault has no storage cap and no advertising. This app exists to sign PDFs; the vault is a convenience beside that. Later we may charge for things that cost money to keep running. We do not sell data, and here we could not: what we hold is sealed bytes. We can see how much room an account takes, because a server has no choice about that. The vault is for documents you reach for, not a photo library or a backup drive. An account that grows far past that gets an email first, asking it to come back within reason.

Three ways in

Opening the vault means unwrapping a copy of the master key with something only you have. Each way in is one sealed copy, stored separately, and you can hold more than one.

Your device keychain, behind Face ID or Touch ID

On iPhone, iPad and Mac the wrapping key sits in the device keychain and opening the vault is a biometric prompt. This is the everyday way in, and the prompt is enforced by the system rather than by our code. The key stays on the device that made it: it is not synchronised anywhere, not even through iCloud, because the keychain will not both synchronise an item and gate it on your face, and we would rather have the gate. A second device is set up once with your recovery code and then remembers. We never receive the key, which also means we cannot revoke it for you: signing a device out and removing it from your account is what cuts off its access.

A passkey, for the browser

A passkey that supports the WebAuthn PRF extension derives the wrapping key in the browser through HKDF-SHA256. The passkey itself stays on your device or in your password manager; we keep its public part and a sealed copy of the master key.

A recovery code, shown once

Twenty-four characters, 120 bits of entropy, turned into a key with PBKDF2-HMAC-SHA256 at 600 000 iterations. It appears when you enable the vault and never again. Write it down and put it somewhere real.

Lose all of them and the documents are gone

We cannot reset a vault, mail you a link, or open it under a court order. No copy of your master key exists anywhere except sealed under your own secrets, so there is nothing for us to recover from and nothing for us to hand over. This is not an oversight waiting for a support tool: a way for us to get you back in is a way in that exists whether or not you asked for it, and it would be available to anyone who could impersonate you convincingly or compel us legally. The price of not having that door is that your last key is genuinely the last one. Keep the recovery code where you keep a passport, and if a document exists nowhere else, keep a copy that does not depend on us.

Sharing happens on your device

Sending a document out of the vault downloads the ciphertext, decrypts it on the device, and hands the plain file to the system share sheet. From there it is an ordinary file: Mail, Messages, AirDrop, whichever you pick, and the destination is your choice rather than ours. We do not create share links. There is no public URL that serves a vault object and no endpoint that hands one over without your own sign-in, so there is no link to leak, to expire, or to be found by someone guessing.

The vault in the browser

On the web, the code that decrypts your files is served by us, on every visit. The Apple apps are signed and delivered by Apple, so they do not change with the website. For the vault, the app is the right place; the browser page is for everything else.

Off until you turn it on

A new account has no vault. There is no master key, no manifest and nothing to decrypt until you enable it on a device, which is where the key is generated. With no passkey and no web access set up, this website cannot decrypt anything at all, even while you are signed in, because it has no way to unwrap the key. None of this touches signing, which happens on your device, with no upload, whether the vault exists or not.

The format is published

Every algorithm, parameter and byte order is written down, because a claim that your files are unreadable to us is only checkable if the format is known. The document names the primitives, the iteration count, the wire encoding, the structure of the manifest, and the attacks the design does not stop. It is the same file the apps and their tests are written against, and it is on this site rather than behind a sign-in on somebody else's.

Read the vault format

The infrastructure, in full

Not a summary. This is everything we operate and everything that leaves your device, which on a product like this should be a short list.

Servers

Our own, in our own data centre. Nothing is rented: BILOUD SRL owns the building, the servers, the racks, the switches and the routers, and is itself the internet provider, so traffic leaves through our own connectivity rather than a landlord's. TapSign does not run on infrastructure we do not control, and there is no third party we could be asked to hand your data to because there is no third party holding it.

Third parties

None. No analytics, no tracking pixels, no advertising networks, no third-party fonts or scripts. The page you are reading loads nothing from another domain.

Email

Sign-in codes leave our own mail server. There is no newsletter, no product announcement and no offer. The only messages we send are about your own account, because you asked for them a moment earlier.

Diagnostics

Off unless you turn it on, which we only ask for while chasing a specific bug. It records the technical exchange with your token or card, strips the names and file paths before anything is sent, and goes only when you press send. Reports are deleted after ninety days.

Desktop update check

Only the copy you download from this site does this: the Windows zip and the Linux .deb or .rpm. They ask https://tapsign.eu/api/v1/app/update once when they start. The request names the platform, the architecture, the package and the build already on the PC. It does not send a document, a certificate or a PIN. The Microsoft Store build, the Flatpak from our repository and the Apple builds do not make this request. Those copies are updated by the store or repository that installed them.

How to check us

Put your phone in airplane mode and sign a document. It works, which is only possible if nothing is being uploaded.
Watch the network from a proxy while signing. You will see no request carrying document bytes.
Open a signed PDF in Adobe Acrobat and inspect the signature properties: the certificate is yours, not ours.
Compare the signed file with the original in a hex editor. The original bytes are untouched; the signature is appended.
Put a file in the vault while watching a proxy. The upload carries one blob of ciphertext and nothing else: no file name, no folder, no extension, nothing for us to file it under.
Ask our API what your own vault holds. It answers with the number of objects, their total size, the encrypted manifest, and how many ways in you have. That is the same list this page gives you, because it is all there is.

Found something wrong?

Tell us before you tell the internet, and we will fix it and credit you. Use the contact form. We do not run a bug bounty yet, but we do answer.

Contact

How your documents stay private