What each credential provider and wallet platform supports — and where the gaps are. Use this to scope deployments, answer pre-sales questions, and avoid promising features that don't exist.
OS-level capabilities determined by Apple, Google, and Samsung — not by the credential provider. These affect the user experience and are consistent across Wavelynx, HID, and LEGIC deployments.
| Capability |  Apple Wallet |  Google Wallet |  Samsung Wallet |
|---|---|---|---|
Can the end-user initiate their own credential provisioning? Whether a cardholder can add a credential to their own wallet without an admin pushing a token or link. Affects the self-service UX you can promise customers.
| ✓Supported Standard Add to Apple Wallet UX — user-initiated from the app or web surface. | ✗Not supported Admin-only token redemption. The user receives a token pushed by the management system; they cannot pull a credential themselves. | ?Unknown / unconfirmed |
Can the end-user suspend or resume their own credential? Whether the cardholder can disable their credential from the device without contacting an admin. Relevant for lost-phone scenarios and self-service offboarding.
| ✓Supported iCloud Lost Mode and Find My allow the user to suspend from any device. Resume via the same path. | ✗Not supported User must contact admin — no in-Wallet suspend path. Admin drives lifecycle changes. | ?Unknown / unconfirmed |
Can the reader force biometric or passcode authentication before credential presentation? Transaction Risk Analysis (TRA) — the reader can signal to the device that elevated authentication is required before the NFC credential is presented. Apple supports this via ECP; Google has no equivalent.
| ✓Supported Reader sets TRA flag via ECP 2.x. Device requires Face ID, Touch ID, or passcode before presenting. Configured per-reader. | ✗Not supported No TRA equivalent in Google Smart Tap. Credential presents without additional device auth. | ?Unknown / unconfirmed |
Can the credential be used on a locked device without unlocking? Express Mode (Apple) / equivalent — tap-and-go without waking or unlocking the device. Critical for high-throughput access points (turnstiles, parking, building entry) where unlock friction is unacceptable.
| ✓Supported Express Mode — credential available without unlocking. Can be combined with TRA for a per-reader decision. | ~Partial / limited Screen must be on (ambient display counts). No true locked-screen NFC presentation equivalent to Express Mode. | ?Unknown / unconfirmed |
Does the credential work after the device battery dies? Power Reserve / dead-battery mode — the NFC chip can continue to respond after the device shuts down. Operationally important for employee access when phones run out of charge.
| ✓Supported Power Reserve Mode — up to ~5 hours of NFC access after device shuts down due to low battery. | ✗Not supported No dead-battery NFC mode. Credential requires device power. | ?Unknown / unconfirmed |
What NFC reader protocol does this wallet use? The wire-level protocol the access reader must speak to communicate with the wallet credential. Determines reader compatibility and firmware requirements.
| ✓Supported Apple ECP (Enhanced Contactless Polling) + VAS (Value Added Services). Reader must support ECP 2.x for full feature parity. Apple ECP protocol reference | ✓Supported Google Smart Tap. Reader requires Smart Tap certification and a Collector ID from Google. | ?Unknown / unconfirmed |
Must reader hardware be certified by the wallet platform? Whether the wallet platform requires readers to be certified/approved before they can present credentials. Affects hardware procurement and site readiness assessments.
| ✓Supported Apple Wallet Access Program — only certified readers can present Apple Wallet credentials. Certification managed per-partner. | ✓Supported Google Smart Tap-compatible readers require a Collector ID issued by Google. Not all NFC readers qualify. | ?Unknown / unconfirmed |
What each credential provider (CP) supports. Some capabilities differ by wallet — hover notes for detail.
| Capability |  Wavelynx |  HID |  LEGIC |
|---|---|---|---|
Can a credential be suspended and resumed without revoking and re-issuing? Suspend/resume preserves the credential on-device but disables it at the reader. Avoids the full re-issuance cost for temporary access changes (leave, investigation, suspension). All major CPs support admin-initiated suspend; user-initiated differs by wallet platform.
| ✓Supported Admin-initiated suspend/resume via Wavelynx Wallet API. Propagated to Apple/Google Wallet. §6 Lifecycle flows — suspend/resume | ✓Supported Admin-initiated via HID Origo credential management API (v2.2 + v3.x). Credential Management — suspend/resume | ✓Supported Admin-initiated lifecycle management via LEGIC Apple CP / Google Access Hub API (step 10 in both flows). Exact API surface pending extranet docs. Step 10 — Manage credential lifecycle |
Can a credential be remotely revoked when a device is reported lost? Lost-device revocation removes the credential from the wallet platform so it can no longer be used, even if the device is offline at the time. The revocation propagates when the device reconnects.
| ✓Supported Revoke via Wavelynx API. Credential removed from wallet platform; device gets the update on next sync. §6.4 Lost-device flow | ✓Supported Revoke via HID Origo API. CloudEvents notification confirms propagation. Events/Callbacks — credential revocation event | ✓Supported Lifecycle management includes revocation (step 10 covers the full lifecycle). API specifics pending extranet docs. |
Can credential metadata be updated without revoking and re-issuing the credential? Some metadata changes (display name, access level) can be pushed to an existing credential in-place. Others — particularly visual card design — require a full revoke + reissue cycle. Affects operational cost of cardholder data changes.
| ✓Supported Wavelynx supports in-place metadata updates via the Wallet API without credential revocation. §6 Post-provisioning updates | ?Unknown / unconfirmed Not explicitly confirmed in HID Origo public docs. | ~Partial / limited Most fields can be updated post-provisioning. EXCEPTION: the card background image is the one field that requires full reissue — it cannot be updated in-place. Confirmed by LEGIC (Q5 of John Harvey email). Q5 — card background image requires reissue |
Does the CP emit webhook / event notifications for lifecycle state changes? Webhooks allow the management system to react to credential state changes in real time (issuance complete, suspension, revocation) without polling. Format and reliability vary by vendor.
| ✓Supported Webhooks with x-api-key auth. HTTPS with optional TLS pinning. Retry behavior not publicly specified. §5.5 Webhook delivery | ✓Supported CloudEvents v1.0 format via HTTPS POST. HID Origo does NOT retry failed deliveries — caller must implement polling fallback. Events/Callbacks — CloudEvents spec | ?Unknown / unconfirmed Not confirmed in available LEGIC sources. Inferred by analogy. Open Question L6 in Wiki — Open Questions. |
Does provisioning require a LEGIC/vendor Mobile SDK in the mobile app? Some credential providers require a vendor-supplied SDK to be bundled in the mobile app to handle the wallet provisioning protocol on-device. Affects mobile app build complexity and SDK maintenance overhead.
| ?Unknown / unconfirmed Wavelynx uses NXP MIFARE2GO for Google — SDK requirements not confirmed in available sources. | ?Unknown / unconfirmed HID Origo SDK requirements for Google Wallet provisioning not confirmed in available sources. | ✓Supported LEGIC Mobile SDK required in the Android app for Google Wallet provisioning. The SDK handles the Google Access Platform protocol. Slide 2 — Mobile SDK labeled in Mobile App actor |
Does provisioning use a token (Google) or wallet pass reference (Apple)? Apple and Google use fundamentally different provisioning handshakes. Apple: the Client Backend delivers a wallet pass reference (credentialProviderId + environmentId + walletCardId) to Apple Wallet Service. Google: the CP issues a token that the Mobile SDK redeems via the Access Platform. Affects backend integration complexity.
| ✓Supported Wallet pass file — Wavelynx assembles and delivers a JWS-signed provisioning bundle to Apple via mTLS. §5.2 Issuance flow | ✓Supported HID Origo mediates via Apple Wallet integration — exact handshake similar to wallet pass approach. | ✓Supported Wallet pass reference flow — Client Backend provides credentialProviderId, environmentId, and walletCardId to Apple Wallet Service. Slide 1 step 7 |
What NFC credential format options are available at project setup? The credential format determines the NFC protocol used at the reader. LEGIC offers two formats for Google Wallet; Apple credential format is fixed by the Apple Credential Provider protocol.
| ?Unknown / unconfirmed | ?Unknown / unconfirmed | ✓Supported Two options at project onboarding: neon (LEGIC proprietary NFC format) or DESFire (NXP MIFARE DESFire). Choice determines reader compatibility — DESFire more common in EU deployments. Slide 2 step 1 — "(neon or DESFire)" |
Is a web-based (browser) provisioning path supported, in addition to in-app? Web provisioning allows a cardholder to add a credential from a browser on any device (typically desktop), then install to their mobile phone. Useful for environments where the mobile app rollout lags credential issuance.
| ✓Supported Wavelynx supports both in-app and web-based provisioning flows. Web flow uses a redirect to wallet.apple.com / Google's web path. §5 — issuance flow variants | ✓Supported HID Origo supports web provisioning (HID Mobile Web Provisioning Flow). AE NFC Cloud provides the web redirect path. Web provisioning flow diagram | ?Unknown / unconfirmed Not confirmed in available LEGIC sources. Extranet Application Notes may clarify. |
How long does end-to-end credential provisioning typically take? The wall-clock time from user tapping "Add to Wallet" to credential available on device. Affects user experience and support expectations. Includes server-side crypto assembly and wallet platform round-trips.
| ✓Supported 20–30 seconds typical (heuristic; consistent with LEGIC range but not independently documented). | ✓Supported 20–30 seconds typical (heuristic; consistent with LEGIC range but not independently documented). | ✓Supported 20–30 seconds typical end-to-end (per LEGIC email Q&A). Q6 — provisioning time estimate |
Are mobile-credential encryption keys independent of physical card keys? When a vendor uses separate key spaces for wallet credentials vs. physical cards, a wallet key compromise does not expose physical card keys — and vice versa. Affects blast radius assessment and key rotation strategy.
| ✗Not supported Wavelynx diversifies per-credential keys from a master keyset that is also used for physical-card encryption. Shared key space. §5.4 Key diversification | ✗Not supported HID Origo key architecture derives from the same master used for Seos physical cards. Shared key space. | ✓Supported LEGIC wallet encryption keys are architecturally independent of physical card encryption keys. This is an explicit LEGIC design choice — confirmed by John Harvey (Q2). Contrast with Wavelynx and HID where both channels derive from a shared master. Q2 — key independence confirmation |
Are credential encryption keys protected by HSM? HSM (Hardware Security Module) backing ensures keys never exist in plaintext outside tamper-resistant hardware. Relevant for compliance certifications and enterprise security reviews.
| ✓Supported Wavelynx uses Google Cloud KMS — keys decrypted in-memory only, never persisted plaintext outside KMS. §5.4 KMS-wrapped master keyset | ✓Supported HID Origo operates HSM-backed key infrastructure for Seos credential keys. Engineering depth limited in public HID docs. | ✓Supported LEGIC Orbit generates keys inside LEGIC HSMs — keys never leave the HSM in plaintext. Recommended path over customer-supplied keys. Q2 — Orbit HSM-backed key generation |
Can the customer supply their own master encryption key? Customer-managed key material allows the customer to retain cryptographic sovereignty — they control the master key and can revoke LEGIC/vendor access. Higher operational complexity but stronger compliance posture for regulated industries.
| ?Unknown / unconfirmed Not confirmed in Wavelynx API docs v1.0.12. | ?Unknown / unconfirmed Not confirmed in HID Origo public API docs. | ✓Supported Supported via API or key ceremony. Customer-supplied keys are an alternative to LEGIC Orbit — but key rotation is only supported on the Orbit path. Q2 — customer-supplied key option |
Does the vendor support credential encryption key rotation? Key rotation replaces the master encryption key without revoking and re-issuing all credentials. Operationally important for long-lived deployments and compliance regimes requiring periodic key refresh.
| ?Unknown / unconfirmed Not documented in Wavelynx API docs v1.0.12. | ?Unknown / unconfirmed Not confirmed in HID Origo public API docs. | ✓Supported Supported when using LEGIC Orbit (HSM path). NOT supported on the customer-supplied-key path. Q4 — key rotation on Orbit path only |
Some capabilities — dead-battery fallback, Express Mode, user-initiated provisioning — are determined by Apple or Google, not by Wavelynx, HID, or LEGIC. When a customer asks "can users add their own credential?", the answer depends on which wallet they're using, not which CP AE chose.
Cells marked ?mean the capability isn't documented in AE's current source set — not that it's absent. When a deal depends on an unknown cell, ask the vendor directly and update this page with a citation.
LEGIC has more unknowns than Wavelynx and HID because primary source depth is still incoming — extranet Application Notes (Apple f=2842, Google f=2395) are not yet accessible. Expect unknowns to resolve once those are obtained.
The diagrams, comparisons, and animated flows aren't built for phones. Open this link on your laptop or desktop browser and you'll see the full reference.
Same Google sign-in as the AE App Hub — you'll be in once you open it on a larger screen.
