What Building for eIDAS and GDPR Taught Me About User Trust

The regulation is not the product

eIDAS — the EU's electronic identification and authentication regulation — defines what makes a digital signature legally valid in Europe. GDPR governs how you handle the data flowing through that signature process. Both are real constraints. Both matter.

The mistake I've seen product teams make is treating compliance as a checklist you hand off to legal and then build around. That gives you a product where the friction lives exactly where it shouldn't: in the moments a user is trying to sign a contract, onboard a customer, or close a deal.

The better frame is: regulation as design input, not design tax. What does eIDAS actually require at each step? Where does it give you discretion? When you read the directive itself — not just a summary — you find more room for user-friendly choices than most teams assume.

Trust is earned in the transitions

A digital signature flow has maybe four moments where a user's trust is actually at stake: when they receive the document, when they're asked to verify their identity, when they apply the signature, and when they get confirmation it worked.

Most of the product work lives in transitions between these steps. A user who gets an email from an address they don't recognize, landing on a page that looks different from the platform they expected, will abandon before they ever sign. That's not a UX problem — it's a trust problem. And it's one that compliance requirements around identity verification can easily make worse if you're not deliberate.

Some things we learned the hard way:

What this taught me about regulatory product design

Building for eIDAS gave me a specific appreciation for what I'd call constraint-first discovery. Before you scope a feature, understand the regulatory constraint fully. Not "is this allowed?" but "what does compliance actually require, and what does it leave open?"

That approach doesn't slow you down. It stops you from building things twice — once the way you imagined, and again after legal reviews the spec.

The other lesson: compliance documentation is a form of user communication. Every time a user is asked to consent, acknowledge, or verify something, that's a product moment. Write it like one.

The trust dividend

Products that handle regulatory complexity gracefully earn something that's hard to buy: the confidence of enterprise buyers who are used to being disappointed. A digital signature product that makes legal validity *feel* obvious — not just technically correct but communicably trustworthy — wins deals that a technically equivalent but confusing product loses.

That's not a compliance outcome. That's a product outcome. And the difference between the two is usually how seriously the PM took the regulation as a design brief.