Frequently asked questions

We build the proof layer for digital identity. Our platform issues and verifies credentials such as age, residency, and professional status. Your business gets an answer it can trust without receiving the underlying personal data. It runs on the eIDAS 2.0 standards we co-authored.

A Danish company built on more than 30 years of cryptographic research, and a spin-off from Aarhus University. Our founders helped turn multiparty computation from theory into something that runs in production. We are based in Aarhus.

Multiparty computation (MPC) lets several parties compute a shared result from data that none of them ever reveals to the others. The inputs stay encrypted throughout, and only the agreed result comes out. It is the cryptography underneath our identity and data-collaboration work. Its first commercial use in the world was a Danish sugar-beet auction we helped run in 2008.

We are chosen in logistics, public healthcare, and manufacturing. We work with governments, enterprises, and technology partners building on top of our platform. We name individual customers only where they have agreed to it, so ask us and we will tell you what we can.

3 applications and the APIs underneath them. VisitorPass is credential-based visitor management. SitePass gives every worker on a site a verified digital ID for check-in, time on site, and gate access. AgeVerify proves a visitor is old enough without exposing their identity documents. The Credential APIs issue and verify credentials directly, for teams building their own flows.

Start in the developer documentation. The Get started guide covers the toolchain. The decentralized identity introduction runs the issuer and verifier locally and issues your first credential.

It depends on the product. Our applications use one: SitePass issues each worker's digital ID to Partisia ID Wallet or into the customer's own app, VisitorPass issues the guest's credential to their wallet, and AgeVerify asks the person's wallet for a single fact. In a flow you build on the Credential APIs, a wallet is one identity source among several, and it is optional. Credentials can come from national eIDs or from credentials you already issue. Your users reach the flow through the web, mobile, or a kiosk you already run.

There are other ways to verify. A SitePass worker without AltID can verify with a passport scan instead, and biometrics can be added where a site needs an extra layer of security. VisitorPass can verify a guest with AltID or MitID in Denmark, or with a passport scan, and EU Digital Identity Wallets follow as they become available.

No. SitePass and VisitorPass are not access control systems. They connect to the access control the site already has, and your system still decides whether a door opens. VisitorPass staff sign in through your existing identity provider, such as Google Workspace or Entra ID.

Yes. That is what the Credential APIs are for. You get the issuing and verification primitives, and you decide what credential you ask for, where you ask for it, and what your service does with the answer.

We do not publish a price list. Scope varies with volume, integration effort, and how you deploy, so we quote per project. Tell us what you are building and we will come back to you.

Ask where people are going: a building with a front desk, or a site with a workforce. VisitorPass is for guests and contractors coming into a building, such as an office, a hospital or a plant. Each visit is checked in and out, and reception runs it. SitePass is for the people who work on a site. Each worker gets a verified digital ID on their phone, their time on site is recorded, and the site or workforce manager runs it. Both run on the same platform.

When people come to you: guests, consultants, contractors and service technicians visiting an office, a hospital or a plant, for an afternoon or for months. A visit starts from a calendar invitation or the dashboard, the guest checks in with their own phone, and their access ends when the visit does.

When a workforce builds, sets up or runs a place for a limited time: a construction site, or a festival or event venue while it is built and taken down. Workers arrive through suppliers and contractors rather than a front desk. Each one is registered in the site's supplier system, verifies with AltID or a passport scan, and gets a site ID card on their phone. On Danish construction sites, SitePass is built for the new ID-card law. A festival's audience is neither product: that is ticketing.

Wherever both kinds of people arrive. On a construction site, SitePass covers the workforce and VisitorPass covers guests and deliveries, who get a guest card and an entry in the guestbook. The site gets worker IDs and guest passes in one solution and one log. A company with offices and sites can run VisitorPass at the office and SitePass on its sites. Both connect to the access control you already have.

It depends on the place, not the person. An electrician servicing an office is a VisitorPass guest. The same electrician working on a construction site is part of the SitePass workforce. Both credentials can sit side by side in the same wallet, so the same phone works for both.

No. Data stays encrypted under your keys, and Partisia never reads it. The verification returns a proof (old enough, resident here, licensed for this) rather than handing over the document behind it, so there is no pile of copied ID data to lose.

Yes, and we co-authored the standards. EU member states must offer their citizens a digital identity wallet by December 2026, and obligated sectors must accept one about a year later. If you operate in the EU, that is the window to plan for.

Analytics are opt-in, anonymized, and cookieless, and nothing loads until you say yes. You can change that choice any time with the Cookie settings button at the bottom of every page. The privacy policy names every processor and how long anything is kept.

Use the contact form and say it is a security report, and it will reach the right people. Our machine-readable policy lives at /.well-known/security.txt in line with RFC 9116. Please give us a reasonable window to fix an issue before disclosing it publicly.