What the check itself costs
Device-to-device authentication means one device checking that another holds a private key, without asking a server. In practice that is a signature check: the verifying device holds a public key it trusts, the other device signs a challenge or a message, and the verifier runs the verification on its own processor.
That work is small. RFC 8032 gives Ed25519 public keys of 32 bytes and signatures of 64 bytes, so very little data has to change hands. Nothing in the check needs a network, a server or a third party. A per-check price is therefore a vendor’s pricing choice, not a cost the cryptography imposes.
The costs live in everything around the check.
Where the costs are
Enrolment and sign-in. Before two devices can check each other offline, each needs to know which keys to trust. That decision is made while a connection exists: a person signs in, and their device key is bound to their account. Hosted identity services that price by monthly active users bill this step. Google Cloud’s Identity Platform, for example, charges per monthly active user for most sign-in methods and charges phone and multi-factor authentication per message sent.
Distributing trust and revocation. Devices need updated lists of trusted keys and of keys that are no longer valid. That means a server to publish them, bandwidth to fetch them when devices are online, and a policy for how stale a list may get. If you run your own certificate authority, add the work of operating it, discussed in whether you need a certificate authority offline.
The SDK’s license. Open-source code is free to use under its license’s conditions. The GNU Affero General Public License, for example, requires in section 13 that a modified version prominently offer all users interacting with it over a network an opportunity to receive its corresponding source. Products that cannot meet such obligations need a commercial license, where the vendor offers one.
Engineering and hardware. Key storage, enrolment flows, error handling, testing on real devices and, for fixed sites, any reader hardware.
How vendors charge
| Cost item | Ways it can be priced |
|---|---|
| Account sign-in | Per monthly active user, with an included quota |
| Phone verification and SMS codes | Per message sent |
| Offline SDK usage | Per user of the offline features, or not metered |
| SDK license | Free under an open-source license, or an annual commercial license |
| Trust and revocation updates | Your own hosting and bandwidth |
The third row is where offline products differ. Bridgefy’s pricing page defines a MAU as a unique user who has interacted with your app through its SDK in a 30-day period, and says users who never touch the offline features do not count. Under that model, the more people use offline features, the more you pay. Others, such as the example below, meter only their hosted services and leave local traffic unmetered.
A published example
Offline Protocol publishes both sides. Local peer-to-peer traffic is never metered on any plan, so devices verifying each other over Bluetooth LE or another local transport add no per-check charge. What is metered is OfflineID, its hosted sign-in service, which counts each end user who signs in to an application at least once in the calendar month (UTC). The Free, Pro and Scale plans cost $0, $99 and $499 a month and include 1,000, 10,000 and 50,000 monthly active users, with $0.02 for each user beyond the quota. A Free organization without a card stops at its quota rather than being billed.
The OfflineID client packages are MIT or ISC licensed. The mesh SDK is free under AGPL-3.0-only, including in production when its obligations are met. Closed-source apps, apps distributed through the Apple App Store and closed-source firmware need a commercial license because they cannot meet those obligations; it is annual and has no published price, and discounts are offered to startups and nonprofits.
Estimating your own cost
- Count sign-ins, not checks. With a sign-in-based meter, the bill follows how many people sign in each month, however many offline checks they make.
- Read the meter’s definition. Find out whether a vendor counts offline use, guest sessions or each of your apps separately.
- Price the license. Decide whether your product can meet the open-source license or needs a commercial one.
- Budget for revocation. Plan how trusted-key updates reach devices that are rarely online, and who runs the server they come from.
- Keep sign-in off the critical path. Hosted sign-in needs a network, so a design that requires it before every local interaction will fail exactly where offline checks are meant to work.