Access control began with universal compatibility—we just didn't call it that at the time, because there wasn’t such a thing as being incompatible. Everyone spoke the same language: 125 kHz proximity cards. However, manufacturers then decided to create their own dialects. Some used ASK (Amplitude Shift Keying), others FSK (Frequency Shift Keying), and eventually PSK (Phase Shift Keying), and EM4100 formats emerged. These are all just different ways of modulating the same 125 kHz frequency to transmit data.
The kicker? They were all broadcasting the same credential data—just in different languages. No encryption, no authentication, just raw data transmission with slight modulation differences. A comparison would be like speaking English versus Spanish: fundamentally similar communication, just with a translated vocabulary.
When 13.56 MHz technology emerged from government applications, it represented a significant leap forward. The higher frequency enables significantly faster data transmission, which is critical for cryptographic operations. Those microseconds of additional bandwidth during a credential presentation make real encryption possible.
This is where we introduced the first "password" into the reader-credential conversation. Technologies such as HID iCLASS, NXP DESFire, MIFARE Classic, and the like all operate at 13.56 MHz, but each implements its own cryptographic protocol. They're using the same communication frequency but different encryption schemes—AES with varying key management approaches, proprietary challenge-response protocols, and different secure messaging implementations.
The result was a massive step forward in security, but the result was that credentials and readers were not cross-compatible. One pair speaking iCLASS fundamentally could not talk to another pair speaking DESFire. Ironically, the drive for security created the lock-in problem we face today.
Here's what organizations need to understand: AES-128 encryption is secure (as of today, more on quantum computing will be discussed later). The question isn't whether the encryption algorithm is strong enough—it demonstrably is in today’s threat landscape. The question is whether you've built a secure system around it.
Think of it like password security. Everyone uses passwords across dozens of websites. That doesn't make passwords fundamentally insecure. But, if you use the same password across 50 sites and one gets compromised, the problem isn't the password mechanism—it's how you deployed it.
The same principle applies to credential encryption. Using a common standard like AES-128 doesn't create vulnerability. Improper key management, inadequate system architecture, or failure to update compromised credentials—those create security vulnerabilities.
Picture this: your front door reader only accepts HID iCLASS credentials. Your parking garage is set up for MIFARE. Your data center uses DESFire. Each system requires a separate management infrastructure, separate credential provisioning, and separate vendors for replacement readers.
This isn't just about inconvenience. It's about architectural constraints. When you design a new building wing, your reader's choices are limited to whatever credentials you've already deployed or those that someone else has deployed before you. When a reader fails, you're hunting for compatible replacements from specific vendors. When you want to add mobile credentials or upgrade to stronger encryption, you're constrained by decades-old decisions.
This fragmentation creates exponential complexity. When your HR team onboards a new employee, they coordinate with IT for network passwords, with security for physical access badges, and with facilities for parking credentials. Each credential might use different technology, require different provisioning systems, and integrate with different management platforms.
When an employee forgets their badge, they can still tailgate into the building—it's an inconvenience, not a hard stop. However, if that same credential were “universal” and thus controlled the employee’s building access, computer login, printer authentication, and secure room entry, then forgetting it would become a full productivity blocker. More accountability and security layers are a byproduct of more “universal” access points throughout an employee's workday.
It’s easy to multiply inefficiencies and vulnerabilities across your organization if you’re not using a universal credential. The lost productivity, the security gaps, the vendor dependencies—they compound quickly.
Obviously, the solution isn't about choosing the "right" proprietary system. It's about establishing standards that work across manufacturers, just like the International Standards Body did after World War I with screw threading. Universal compatibility means building access control systems on common building blocks—secure, interoperable foundations that let you choose the best tools for your needs as your ecosystem and the threat landscape evolve.
Standards don't compromise security—they enable it by allowing you to focus on system architecture rather than protocol compatibility.
In Part 2, "Why Universal Readers Are the Bridge to Better Security" we'll explore how modern universal readers support migration strategies, why the industry needs to prepare for post-quantum cryptography, and how open standards drive innovation rather than stifle it.
.png){kind=small}
.png)
.png)
