Issue and manage
Connect your source system. Manage issuance, changes and revocation.
Present and verify
Check the required proof, using prepared trust and status data when offline.
Connect the result
Return the result to your process. Retain only necessary information.
Validate before deployment
The pilot validates devices, formats and offline limits. ZKP and EUDI compatibility require implementation-specific evidence.
Assess your workflow →Scan QR. Tap NFC. Connect with BLE.
Supported devices and transfer methods are agreed and tested in your pilot.
Can QR codes work offline?
Yes. A QR code can carry signed data or start a local connection, such as BLE. A QR code that only points to a website needs a connection to retrieve it. Offline verification also needs the correct trusted keys, validity rules and sufficiently fresh status data.
Are QR, NFC and BLE different security levels?
They are ways to start a session or transfer data. QR can start a local session, NFC enables tap-based engagement or supported data transfer, and BLE carries data between nearby devices. The credential protocol must handle consent, cryptographic verification and replay protection. The radio or QR code alone does not provide those guarantees.
What is agreed before deployment?
Wallet and reader devices, credential format, QR/NFC/BLE flow, proof size, security tests and the maximum offline period. We verify the selected combination before promising support. Revocation updates and trust data need periodic refresh; an offline check cannot know about changes it has not received.