Skip to main content
Strong Customer Authentication (SCA) makes the end user, not your platform, the party who authorizes a sensitive operation. The end user approves with a WebAuthn passkey. Each approval binds to one operation: this amount, this destination, this account. It works for nothing else. SCA applies to end users onboarded under Circle’s EEA-regulated entity. Scope follows each end user, not your platform. See Which end users require SCA. To implement the flow, see How-to: Implement Strong Customer Authentication.

​
Which end users require SCA

Circle determines whether SCA applies to each end user, and reports it as sca.required on GET /v1/accounts/passkeys:
  • true: protected operations for this end user return HTTP 428 without SCA headers.
  • false: Circle doesn’t require SCA for this end user.
  • null: Circle couldn’t determine the requirement, for example during a temporary outage. It isn’t the same as false, and it isn’t a lasting answer.
A true or false answer is safe to store. The protected endpoint returns HTTP 428 whenever SCA is required, so an out-of-date answer can’t let an operation through without SCA. SCA isn’t limited to end users who require it. A platform can apply one approval flow to every end user, with the same flow and headers. Circle verifies the headers whenever a request carries them, and refuses an invalid, expired, or mismatched approval, or a request with only one of the two headers, with the same error an end user who requires SCA would get. First-party requests that carry no end user, such as adding or removing a recipient address your platform owns, or linking your platform’s own wire bank account, never require SCA.

​
Key terms

​
What an approval proves

A passkey prompt on its own proves only that someone unlocked a device. SCA proves more than that, because the challenge records the operation before the end user sees it. Your backend sends the exact operation body to Circle as the challenge intent. Circle stores it and returns a challenge. The ceremony signs that challenge, and Circle accepts the resulting assertion only with the matching request. A valid assertion therefore establishes three things at once:
  • Who approved. The end user holds the passkey enrolled for their clientEntityId.
  • What they approved. The request body Circle verifies is the same body it recorded in the intent. Changing the amount, the destination, or any other field invalidates the approval and returns error code 420047.
  • That the approval is fresh. A challenge is single-use and expires in minutes, so an intercepted assertion cannot be replayed later or applied to a second operation.
The second point is the property that matters most. Without intent binding, a compromised or buggy frontend could show the end user one transfer and submit another. Intent binding removes that gap: the operation Circle processes is the operation the end user saw.

​
Trust boundary

Circle is the WebAuthn relying party, not your platform. The end user registers the passkey against Circle, the ceremony runs in a Circle-hosted iframe, and Circle verifies the assertion. Your app embeds the iframe and moves opaque tokens between your frontend and your backend. Two consequences follow from this split:
  • Your app never renders the approval text. The iframe fetches the operation description from Circle and displays it. The summary field on the challenge response is a record for your logs, not a source for a confirmation screen you build yourself.
  • Your origin must be registered. Circle runs a ceremony only for an origin you registered with your support team. Register sandbox and production separately. This stops an unrelated site from driving a ceremony against your end users.

​
The two ceremonies

Enrollment must complete before an end user who requires SCA attempts any protected operation. You choose when to prompt for it, for example during onboarding or in account settings. Enrolling before the first protected operation means that operation needs only one ceremony, not two.

​
Object lifetimes

Every object in the flow is short-lived, which limits the window in which an intercepted token is useful.

​
Passkeys across devices

A passkey may sync across the end user’s devices through iCloud Keychain, Google Password Manager, or a similar service, depending on their platform. A passkey enrolled on a phone may therefore be available on a laptop without re-enrolling. The reverse also holds. An end user on a device with no synced passkey cannot approve anything until they enroll again. Treat enrollment as a state you check, not a one-time setup step you assume succeeded.

​
Protected operations

The list covers two categories: operations that move value, and operations that change which destinations are trusted. Circle gates address book and bank account changes too. Otherwise one approval would leave every later transfer to that destination unattended.

​
What SCA does not cover

SCA answers whether the end user approved an operation. It does not answer whether Circle should process it.
  • Risk screening and limits still apply. A protected endpoint can accept a valid assertion, return 201, and the operation can still settle as failed after screening. See Limits and risk ratings and Transaction states.
  • SCA is not your app’s login. You remain responsible for authenticating the end user in your own application and for calling Circle on behalf of the right clientEntityId.
  • SCA is separate from how you authenticate to Circle. SCA verifies the end user. Your platform authenticates to Circle at the entity level with your API key and, for EU/EEA entities under MiCA, mutual TLS (mTLS). mTLS is enforced against your entity’s API traffic as the distributor, not per end user or per clientEntityId. See How mTLS authentication works.
  • SCA does not cover read operations. Only the operations listed in Protected operations require an assertion.