Devices

A device is a first-class hardware principal, on par with a user — the holder of a TPM/Secure-Enclave key.

Three layers (key ≠ device ≠ person)

• Device identity — one record per physical authenticator, keyed by its globally-unique credential ID (the passkey’s credential ID). The key-holder. It is never deleted — only its status changes.
• Device binding — per-org trust (the same device identity can be trusted by several organizations). Org-scoped operations key on this.
• Connected ID — the person’s membership (Connected ID).

A personal seal is not owned by an org — it accesses orgs

A personal passkey (owner type User) is the person’s own key; it does not belong to any single organization. The organizations it can act in are expressed purely as device bindings.

So My Devices groups a personal seal under “Personal”, and lists the orgs it can reach as accessible-org chips beneath it — one physical device, many org accesses. Only a company-issued asset (owner type Organization) is owned by, and grouped under, its organization. Because the identity is keyed by credential ID, the same physical machine accessing a new org just adds a binding — it never spawns a second device or seal (a hardware key cannot be copied to another machine).

Ownership decides revocation rights

The owner type is User (a personal device) or Organization (a company asset):

• Personal device — the user controls the key; an org can only revoke its trust (binding), not kill the key.
• Company asset — the org controls the key and can bulk-revoke.

Assurance axes (measured at enrollment, not policy)

Each device records whether its key is hardware-backed (TPM / Secure Enclave), whether the user was verified (biometric / PIN), whether the key can be backed up and synced (if not, it is device-bound), the authenticator model (AAGUID) and a security level. These values are covered by a content hash, so changing them outside the platform is detected.

The current device is identified by the session device_id claim (the credential ID); status changes and deletion enforce anti-lockout — see Devices reference.

Enrolling a new device is a step-up event

A seal is device-bound and unphishable, but that only protects the key. Enrolling a new device mints a new trusted credential, so it must be gated by more than “you hold a valid session” — an email magic link or a social token is an identifier, not a secret, and could be phished. The first device is covered by account creation; from the second device onward, enrolling a seal requires a step-up. Without one, the enrollment call answers STEP_UP_REQUIRED and no key is registered.

The primary path everywhere is device-to-device approval, because it costs nothing, works worldwide, and is immune to SIM-swap:

How the new device is approved	What happens
Approval from a device you already sealed	The new device asks for approval, and your signed-in sessions are notified in real time. You approve on an existing sealed device with your fingerprint / PIN — no email, no SMS. The approval is bound to that one request, is valid for 5 minutes and can be used once. Proving physical possession of a device you already trust is what authorizes the new one.
Korean identity verification	PortOne / carrier 본인인증 (PASS), completed within the last 15 minutes. It binds a real legal name and phone possession and is not defeated by a SIM swap.

Re-enrolling on a browser where you have already completed a seal ceremony — for example after removing that device from your list — does not ask for a step-up again.

A bare SMS one-time code is never accepted for enrolling a device — SIM-swap and SS7 interception make a knowable phone number too weak to be the factor for minting a new key.

Identity verification during organization setup

• Sole proprietorship — the setup wizard has a verify step where the owner verifies a phone number by one-time code, or completes Korean identity verification. The result is stored with the organization, and setup cannot be completed without it (400 IDENTITY_VERIFICATION_REQUIRED).
• Corporation — the representative director is verified. If the creator is the representative, the earlier verification satisfies it (skipped); if the creator is not the representative, the representative verifies separately, as the legally accountable party.