Proving who signed, without storing a CPR number

A signed contract is only as trustworthy as the proof of who signed it. For Danish businesses, the strongest version of that proof is MitID: a signer authenticates with the national eID system, and the platform can say with confidence that a specific, verified person signed a specific document. The obvious way to build that is to store the CPR number MitID hands back, since a CPR number is the most unambiguous identifier a Danish system has. Signedy deliberately doesn't do that.

Three ways to sign, one question of assurance

Signedy supports three signing methods on a per-form basis: drawing a signature, typing a name, or signing through an eID like MitID. Each represents a different level of assurance. A drawn or typed signature is fine for low-stakes internal approvals. An eID signature is what you want when the document needs to hold up legally, an engagement letter, an NDA, an employment contract, because it ties the signature to a government-verified identity rather than just whatever name someone typed into a box.

The eID integration runs through Criipto, a broker that handles the actual MitID authentication flow so Signedy doesn't have to implement the protocol itself. What Criipto hands back after a successful authentication includes enough information to prove identity was verified, including the CPR number if the integration is configured to request it.

Storing a verified token instead of the number itself

Signedy's integration is built to keep a verified token from that exchange rather than persisting the CPR number in its own database. The token is proof that verification happened, tied to that specific signing event, without being the sensitive identifier itself.

The practical difference matters. A CPR number is a permanent, reusable identifier, the kind of data that turns a database into a much bigger liability if it's ever exposed, and the kind of data GDPR treats with extra weight precisely because of how much it can be tied back to a real person across contexts. A verification token tied to one signing event doesn't carry that same risk. If Signedy's database were somehow compromised, an attacker would find proof that verified signings happened, not a list of Danish citizens' national ID numbers.

Privacy as a design constraint, not an afterthought

This wasn't a case of building the obvious thing first and locking it down later. The decision to keep a token instead of the number shaped how the Criipto integration was built from the start, what gets requested from the authentication flow, what gets persisted afterward, and what the audit trail actually records. Getting this right after the fact, once CPR numbers were already flowing into the database, would have meant a much harder retrofit: migrating existing records, auditing every place the number was read, and hoping nothing downstream had come to depend on having it.

For a platform whose entire value proposition rests on being trusted with legally significant documents, that trust has to extend to how it handles the identity data behind those signatures, not just the documents themselves.

More on how Signedy's identity verification fits together is on its product page.