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)

DeviceIdentity — one row per physical authenticator, keyed by a globally-unique CredentialId (= base64 credential id, 1:1 with UserCredential). The key-holder. Never deleted — only Status transitions.
DeviceBinding — per-org trust (the same DeviceIdentity can be trusted by multiple orgs). Org-scoped operations key on this.
ConnectedId — the person’s membership (Connected ID).

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

A personal passkey (BYOD, OwnerType = User) is the person’s own key; it does not belong to any single organization. Its DeviceIdentity.OrganizationId is therefore always anchored to the system org (“Personal”) — the organizations it can act in are expressed purely as DeviceBinding rows.

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 (OwnerType = Organization) is owned by, and grouped under, its organization. Because the identity is keyed by CredentialId, 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

OwnerType = User (BYOD) or Organization (ASSET):

BYOD (OwnerUserId) — the user controls the key; an org can only revoke its trust (binding), not kill the key.
ASSET (OwnerOrgId) — the org controls the key and can bulk-revoke.

Assurance axes (measured at enrollment, not policy)

IsHardwareBacked (TPM/SE), UserVerified (biometric/PIN), BackupEligible (key syncable — false = device-bound), plus Aaguid and SecurityLevel. These are tamper-protected via IContentHashable (ContentHash over GetHashableFields).

The current device is identified by the session device_id claim (= credentialId); status/delete 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.

The step-up is satisfied differently by region, but the primary path everywhere is device-to-device approval, because it costs nothing, works worldwide, and is immune to SIM-swap:

Situation	How the new device is approved
You already have a sealed device (any region)	The server pushes an approval request to one of your existing sealed devices in real time. You approve there with your fingerprint / PIN — no email, no SMS. Proving physical possession of a device you already trust is what authorizes the new one (the pattern Apple and Google use).
Korea, no existing device	Identity verification — PortOne / carrier 본인인증 (PASS), done once. It binds a real legal name + phone possession and is not defeated by a SIM swap.
Outside Korea, no existing device	Phone verification is used only as a last-resort fallback, and never as a bare SMS one-time code on its own.

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

Identity binding at organization creation

Identity is bound once, when an organization is created:

Sole proprietorship — the owner completes 본인인증 once in the create dialog.
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.