How to make an NFC pass scan as static UID
Updated June 23, 2025 05:43
TL;DR: Turn your phone into a card in four steps.
- 1. Create a Wallet pass template that defines your credential file format.
- 2. Issue a Wallet pass whose NFC payload is locked to one fixed identifier.
- 3. Provision the pass into your Apple or Google Wallet and confirm it's not expired.
- 4. Tap your phone onto any Wallet certified reader and watch legacy systems treat the phone like a physical key card.
Developers frequently need to integrate new technologies into existing systems to offer more compatibility and convenience. Legacy NFC systems often rely on static ids off of NFC cards and keyfobs to react. Once detected by the reader, a connected computer could open a gate or redeem a reward. Now that mobile phones and smart watches have NFC chips built-in, it makes sense to include them in these legacy systems. I much rather carry my phone or watch than a bunch of cards and keyfobs, wouldn't you??
(Full step-by-step and reader setup below.)
Why do legacy readers insist on static UIDs?
Legacy 13.56 MHz readers were engineered around MiFare Ultralight and other NFC Forum Type 2 tags, whose UID is set at the factory and never changes. That immutability made each tap a one-step operation—read the number, pass it to the host—perfect for a quick database lookup. In the late-1990s microcontroller world, this extreme simplicity kept hardware costs low and transaction times under 200 ms, a must for transit gates and door strikes where users expect an instant beep.
As deployments ballooned into the millions, chip makers stretched card UIDs from 4 bytes to 7 bytes to curb collisions, yet the “one-number-per-card” paradigm stayed. Re-flashing or replacing every bus validator, turnstile, and office badge reader was too expensive to consider new ways of validating identity. In short, static identifiers are a product of early hardware constraints, and the sheer scale of legacy infrastructure keeps that design choice alive.
What changed? Dynamic UIDs and encryption
As NFC card deployments exploded, the value of each tap—and the incentive for fraud—rose in lockstep. To enhance security and privacy, engineers introduced dynamic or rolling UIDs under the NFC Forum’s Type 4 specification. Unlike static UIDs, dynamic identifiers change with every tap, either presenting a fresh ID or a unique cryptogram.
However, dynamic UIDs introduced considerable complexity, even without encryption. Interacting with these tags requires developers to craft low-level command sequences called APDUs and navigate interfaces like CCID, PCSC, and ISO-7816. Despite its complexity, the hardened security of Type 4 tags has proven successful, and now secures contactless EMV cards along with every credential virtualized inside Apple Wallet or Google Wallet, making static numbers the exception rather than the rule.
Key point: Wallet passes never expose a static UID by default, so we have to embed one ourselves.
How do Apple and Google pick the right pass?
When you tap your phone to pay or unlock doors, Apple and Google Wallets need to rapidly select the correct pass from potentially dozens stored on the device. Both platforms rely on distinct NFC-based protocols optimized for specific use cases, all built on dynamic UIDs. Each protocol requires sending specialized Application Protocol Data Units (APDUs), commands standardized in ISO 7816-4, to select, validate, and decode the data they contain. Currently, there are three main protocols supported:
Contactless EMV cards are the Tap to Pay credit and debit cards commonly used around the world. When stored in a mobile wallet, they gain an extra layer of protection because the phone can require biometric authentication for each transaction. The EMV contactless protocol is widely adopted and works with most point-of-sale terminals. It even works on phones with NFC hardware running iOS 17.0+ or Android 10+.
Aliro passes are used for unattended access control and function differently depending on the platform. Apple Wallet uses a proprietary Enhanced Contactless Polling mode that lets readers automatically select the right pass—even when the iPhone is powered off, a feature called Express Mode. Google Wallet uses standard Host Card Emulation (HCE), which relies on regular APDU commands to read the pass. Aliro is a new open standard that not only features tap-to-unlock but unlock-on-approach and credential interoperability across mobile wallets as well.
VAS passes are used for things like loyalty programs, coupons, event tickets, and boarding passes. To work properly, NFC readers must support the Apple VAS and Google SmartTap protocols so they can detect and decrypt the pass. Some phones can read VAS passes from others using their NFC hardware, but this is still limited in capability (more details here).
Integrating mobile phones into legacy NFC systems is difficult because Apple and Google Wallets use dynamic UIDs, special NFC modes, and more complex pass setup processes. Legacy systems that were originally built for simple, static UID cards and keyfobs, will need to upgrade their reader frontend to pick the right pass and decode it properly. The backend with access logic, signaling, and actuation can remain unchanged enabling a smooth transition.
Making NFC easy with PassNinja
PassNinja makes it simple to use your phone like an NFC card by issuing passes through Apple and Google Wallet. You'll need to sign up for an account and select a pass template with the card type you want to emulate. Right now we support Event Tickets, Access Control keys, Loyalty cards, and Coupons but adding more soon.
| Step | Action | Tool |
| 1 | Create a Wallet pass template | PassNinja Dashboard |
| 2 | Fund the project (credit card or account credits) | Payment tab |
| 3 | Set the nfc-message field to your desired UID (e.g., 04A1B2C3D4) | API / UI |
| 4 | Issue the pass via SMS or email | POST /v1/passes/ptk_0x123 |
| 5 | Test with a VAS-certified reader | See next paragraph |
Once you have the pass installed on your phone, you'll need an NFC reader that supports it and is set to detect your pass template. We recommend the DotOrigin VTAP100 since it's certified for all the Wallet protocols and doesn't require specialized hardware or software to configure. If you want your passes to work out-of-the-box, we sell the VTAP along with a few other readers pre-configured and with fast shipping (<2 days US domestic, <6 days international) on our webstore.
And there you have it. An Apple or Google Wallet pass that scans as a static UID over NFC for you to easily integrate into any legacy systems. What's great is that the VTAP100 supports NFC Forum Type 1 through 3 tags as well so physical cards and keyfobs will still work!
Conclusion
In this guide we went through some NFC history as it relates to static and dynamic UIDs. We covered how dynamic UIDs are more secure and the only option supported by Apple and Google Wallets. We then showed you how PassNinja lets you bridge the gap between the wallets and legacy systems so you can integrate mobile devices and smart watches easily. We are excited to deliver a better experience to your users in every way.
If you have any feedback on this article, let us know!