---
title: Passkey signatures as evidence in Japan
lede: How Japanese law treats signatures and electronic signatures, where a passkey signature fits, what is still undecided, and what a product needs to add around it.
shelf: essays
desk: legal
edition: 1
source: Code of Civil Procedure, Article 228 (e-Gov) | https://laws.e-gov.go.jp/law/408AC0000000109 | 2026-10-10
source: Act on Electronic Signatures and Certification Business, Articles 2 and 3 (e-Gov) | https://laws.e-gov.go.jp/law/412AC0000000102 | 2026-10-10
source: Digital Agency and Ministry of Justice, Q&A on Article 3 of the Electronic Signatures Act (revised 9 January 2024, in Japanese) | https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/517ca59b-6ea4-4179-a338-8d1b51a4d40b/4ae659c2/20240109_digitalsign_qa_01.pdf | 2026-10-10
source: W3C Web Authentication Level 3 | https://www.w3.org/TR/webauthn-3/ | 2026-10-10
source: RFC 3161 Time-Stamp Protocol | https://www.rfc-editor.org/rfc/rfc3161 | 2026-10-10
---

## The starting point: proving a document is genuine

In Japanese civil litigation, the party relying on a document has to prove that it was genuinely made by the person it is attributed to. The Code of Civil Procedure then gives a shortcut: a private document bearing the person's signature or seal impression is presumed to be genuine[^1]. That second clause is where the hanko has done its work for decades.

Electronic records got their own version of the shortcut in the Act on Electronic Signatures and Certification Business.

## What the Electronic Signatures Act says

Article 2 defines an electronic signature as a measure applied to information that does two things: it shows that the information was created by the person who applied the measure, and it makes it possible to confirm whether the information has been altered[^2].

Article 3 then presumes that an electronic record was genuinely made when it carries the person's own electronic signature. It applies only to signatures that, through proper management of the codes and objects needed to make them, only that person can make[^2].

The government's Q&A on Article 3, revised in January 2024, reads two requirements into this. The code used for the signature must be one that others cannot easily reproduce (uniqueness), and the signature must be made on the person's own instruction[^3]. The Q&A addresses services that sign with the provider's own key on the user's instruction. For those, it asks for sufficient uniqueness both in how the user is authenticated and in the provider's internal process, and gives two-factor authentication as an example[^3].

## Where a passkey signature fits

A passkey signature is made with a private key held on the user's device. The key doesn't leave the authenticator, and each signature passes a local check: a face, a fingerprint, or a PIN[^4]. In Clavis, what gets signed is a hash of the operation, and the one line shown to the user (product name, verified host, operation name) is bound into the signature as well.

Against Article 2, that is close to the shape the definition describes: the signature points to the key holder, and any change to the signed content breaks it.

Against Article 3, it is strong on uniqueness: a key held by the authenticator plus a local check is two factors in one gesture. The open questions are elsewhere.

- **Synced passkeys.** A passkey that syncs across a person's devices, or a device shared within a family, weakens the claim that only that person could have signed. The authenticator reports whether a credential is eligible for backup[^4]; whether to record that, or to accept only device-bound passkeys, is a product decision.
- **Who the key belongs to.** The presumption assumes the signature is the person's own. A passkey proves possession of a key, not a legal identity. Linking the key to a named person is the job of your identity checks at registration.

Whether the Article 3 presumption extends to passkey signatures is not settled by any primary source we have found. In the end, a court decides on the facts.

## What to add around the signature

1. **Identity.** Record how and when you verified the person who registered the passkey. Put a reference to that check (not the personal data itself) into the content being signed, so the signature binds it too.
2. **The content itself.** Keep what was signed, not only its hash. A hash alone can't show what someone agreed to once the content is gone.
3. **Time.** Anchoring records in a ledger with a third-party timestamp makes it easier to show that a record existed at a point in time[^5].
4. **A plain description.** When you explain a passkey signature to a counterparty or a court, describe what it does and doesn't show. Overclaiming invites the argument you least want.

## In one sentence

> A passkey signature is a record, checkable later, that a particular passkey signed this content at this time. Who stood behind the passkey, and whether the content meets any legal requirement for writing, depends on your own procedures for identity, consent, and retention.

## Next

- [Recording consent under Japan's APPI](/en/notes/recording-consent-in-japan)
- [Sending personal data out of Japan](/en/notes/sending-personal-data-out-of-japan)
