By SafePath Tech Solutions · Reviewed October 22, 2026
A credential is your digital key. It can live in a card, a fob, or a phone. Here are the three choices most buyers need to understand first.
Like a badge that says its number.
Many older prox cards use a fixed identity that can be copied. They may still work, but they deserve an upgrade plan.
Like a badge with a secret handshake.
A properly set-up secure card and reader check each other before access is considered. DESFire is one example. The reader must use its secure features.
Your phone becomes your badge.
Bluetooth or NFC connects a supported phone to the reader. The credential service, phone, and reader must work together. Keep a backup plan for people without a usable phone.
The card is only one part.
- Your keyThe card, fob, or phone.
- The readerChecks the key.
- The controllerChecks permission and opens the door.
- The softwareManages people and rules.
A new card will not make an old reader secure. The parts need to match, and the connection between the reader and controller needs protection too.
Five questions before you buy.
- Does it check a genuine credential, or only read a number?
- Will it work with our readers and door system?
- Can we quickly turn off a lost card or phone?
- Who controls new credentials, replacements, and fees?
- What is the backup for a dead phone or a visitor?
Our practical starting point.
Evaluate a supported secure smart card or mobile credential, with matching readers and a protected reader connection. You may be able to keep useful door equipment. Start with an assessment of what you already have.
See what can stay in an access-control upgrade ↗Questions worth asking.
What does encryption mean?
It scrambles information so it cannot be understood without the right secret key. Authentication checks that a credential is genuine. A secure system needs the right features switched on, not just a security label on the box.
Is every smart card the same?
No. MIFARE is a family name: Classic, Plus, and DESFire are different. Ask for the exact technology and how it will be used. A secure card read only by its public serial number loses the benefit of its secure application.
Is Bluetooth safer than NFC?
Those names describe how a phone talks to a reader. Security also depends on the credential, service, and configuration. Compare the complete solution.
Must we replace every door?
Not necessarily. Suitable locks and wiring can often stay after inspection. Panels, readers, software, and credentials need their own compatibility review.
Need the technical detail? Compare all credential types, encryption, and readers.
Full credential comparison.
| Credential | Plain-language explanation | Main caution | What it needs |
|---|---|---|---|
| Legacy 125 kHz prox | A familiar tap card or fob, usually presenting a fixed identity. | Common legacy implementations lack modern cryptographic authentication and are vulnerable to copying. | A compatible low-frequency reader and supported card format. |
| MIFARE Classic | An older 13.56 MHz smart-card family using Crypto1. | Not equivalent to DESFire; known security limitations. NXP does not recommend it for new designs. | A matching reader/application; assess migration rather than just reissuing the same technology. |
| MIFARE Plus | A migration-oriented family with security levels. | Compatibility mode is not the same as AES-protected SL3 operation. | Readers, keys, and application configuration supporting the chosen secure mode. |
| MIFARE DESFire EV2/EV3 | A secure smart-card platform supporting authenticated applications and AES-128. | Reading its serial number alone bypasses the benefit of a protected application. | A reader supporting the exact application, keys, and configuration—not merely the frequency. |
| Other secure smart cards, including Seos | Vendor credential systems with protected identities and authentication. | Families, generations, key programs, and reader support differ. | An explicitly supported credential/reader pairing and issuance rights. |
| Mobile Bluetooth (BLE) | An app-based credential communicates with a reader over Bluetooth. | Phone compatibility, app permissions, range, battery, and licensing matter. | Compatible BLE readers, a supported mobile service, and enrolled phones. |
| Mobile NFC / wallet | A phone or wearable taps near a reader. | NFC support alone does not guarantee a particular wallet badge works. | Approved credential service, wallet/device support, and compatible reader firmware. |
| PIN / QR / barcode | A code is typed or presented, often for temporary access. | Shared PINs and static images can be shared; expiry is not identity proof. | Suitable keypad/scanner and carefully scoped, expiring permissions. |
| Magnetic stripe | A card is swiped through a reader. | Conventional static stripe data can be copied; worn stripes can fail. | A compatible swipe reader; assess replacement for new security needs. |
| Long-range vehicle tags | A tag is read at a parking lane or gate. | Range and security vary; do not assume every UHF tag authenticates securely. | A matched vehicle reader/tag system and a carefully planned read zone. |
| PIV / certificate-based credentials | A smart credential can prove identity using a digital certificate. | Reading only a card ID is not certificate authentication. | Compatible readers, software, trust configuration, and credential validation. |
| Biometrics | A reader checks a fingerprint or other physical characteristic. | Review privacy, enrollment, false rejections, accessibility, and fallback. | Supported biometric hardware/software and an approved data-handling process. |
Why legacy prox deserves a migration plan.
Common legacy prox cards act more like an identifier than a protected conversation. A copied identifier can be accepted as the original. Replacing the plastic without changing the technology does not solve that weakness. Inventory the cards and readers, prioritize higher-risk openings, and plan a practical transition.
Source: HID on legacy credential risks
“MIFARE” is a family, not a security rating.
Classic, Plus, and DESFire are different technologies. Classic uses Crypto1 and has documented weaknesses; NXP marks Classic EV1 as not recommended for new designs. Plus supports migration between security levels, so ask which mode is actually active. A 13.56 MHz label alone does not establish strong protection.
Source: NXP MIFARE Classic family · NXP Classic EV1 lifecycle guidance · NXP MIFARE Plus family
What DESFire changes—and what it does not.
DESFire EV2/EV3 supports AES-128 and mutual authentication: the card and reader can prove they know the right secrets before protected information is used. Specify the secure application, unique/diversified keys where supported, and reader configuration. If a reader takes only the public card serial number (UID/CSN), buying DESFire cards has not delivered that authenticated design.
Source: NXP DESFire EV3 capabilities
Encryption in plain language.
Encryption protects information using a secret key. Authentication checks that the credential is genuine; mutual authentication checks both sides. AES-128 is a modern algorithm supported by DESFire; AES-256 in a brochure may refer to a different part of the system. DES/3DES and Crypto1 are older schemes. Ask which protection is active at each link, rather than choosing by the largest number. “26-bit” or “37-bit” describes a credential number format, not encryption strength.
The reader must match more than the card’s frequency.
Verify the exact credential family, secure application, key set, reader model, firmware, and output format. A multi-technology reader can ease a phased migration but may still accept weaker legacy credentials. Agree when legacy modes and serial-number-only reads will be disabled, and test the intended secure mode before rollout.
Bluetooth and NFC describe the connection.
They are not interchangeable security ratings. A mobile system also needs a secure credential service, enrollment process, supported readers, and compatible phones. Test an app-based Bluetooth credential and any wallet/NFC option separately. Check screen-lock requirements, permissions, tap experience, range, battery behavior, replacements, subscriptions, and offline operation. Do not assume every phone or wearable has the same capabilities.
Source: HID mobile credential FAQ · HID supported mobile devices
Protect the second link: reader to controller.
A secure card can still feed a poorly protected reader connection. Legacy Wiegand does not provide encrypted reader-to-panel communication. OSDP supports supervised, two-way communication and Secure Channel encryption. Require supported hardware, actual Secure Channel configuration, and commissioning evidence. OSDP without Secure Channel is not the same as an encrypted link.
Source: SIA OSDP overview
Think about ownership and the day after a loss.
Document who can issue, revoke, replace, and order credentials; who controls application keys; and how authorized future providers receive needed access securely. Customer-managed keys can support independence but require responsible custody and recovery. Never place keys or credential secrets in a public contact form. Test how quickly lost cards and phones are disabled, including at disconnected doors.
Use extra factors where the risk warrants them.
A card plus an individual PIN or supported biometric check can add assurance. Two items do not automatically mean two independent factors, and a phone’s screen lock is not automatically a door-enforced second factor. Ask how the selected system enforces the policy. Biometrics need a clear enrollment, privacy, retention, and alternative-access process.
Move in phases without keeping weak modes forever.
Start with an inventory and a representative pilot. Confirm panel formats, reader wiring/power, secure applications, enrollment tools, mobile services, and staff training. Dual-technology cards can bridge old and new readers, but keep a deadline to remove legacy acceptance. Include visitors, contractors, non-phone users, accessibility, and emergency procedures.
Technical proposal checklist.
- Exact credential technology, application, security mode, and number format
- Reader model/firmware, supported keys, and secure-mode configuration
- OSDP Secure Channel support, wiring assessment, and tested activation
- Issuance/revocation process, key custody, and future ordering rights
- Mobile device/wallet compatibility, recurring fees, and fallback options
- A phased migration with a date for disabling legacy acceptance
Ask for a normal-user demonstration.
Enroll an authorized test credential, use it at the pilot door, revoke it, and verify denial and audit records. Demonstrate a replacement phone and a non-phone alternative. Have the provider show the configured secure application and reader link without exposing secret keys.
Let’s make your next security decision a confident one.
A new facility. An aging system. A challenge you need to solve. Start here.