It authenticates. The card and the reader prove they share a secret key, so nothing reusable ever crosses the air gap.

A proximity card broadcasts a fixed number to whatever asks. A smart card responds to a challenge with a computed answer that is different every time.

Recording the exchange therefore gains an attacker nothing, which is the whole point of the change.

Smart cards also carry storage, so they can hold more than one application and more than one identifier.

Physically the reader looks the same and mounts the same way. The difference is entirely in the protocol and in the key management behind it.

Read range is typically shorter than 125 kHz proximity, which is a genuine trade and occasionally surprises people migrating between the two.

Each card is issued a key derived from a master key and the card's own unique identifier, so extracting one card's key does not unlock the rest.

Without diversification, every card in the population shares one key. A single card successfully attacked in a laboratory compromises the whole site.

With diversification, the attacker who defeats one card has one card's key and nothing more.

The master key then becomes the thing that must be protected, and it should live under a documented custody arrangement rather than in an installer's laptop.

Ask the integrator directly whether keys are diversified and where the master is held. The answer is often revealing.

Plan for rotation too. A key that can never be changed is a key that will eventually be the wrong one.

Yes - a smart card system left on published default keys offers little more protection than the technology it replaced.

Card families ship with well-known default keys so that development and testing are possible. Those values are documented publicly.

A system commissioned without changing them can be read and written by anyone with an ordinary reader and the documentation.

This happens more often than the industry likes to admit, usually because the site specified 'smart cards' and no one owned the key management question.

Make it a commissioning deliverable: site-specific keys loaded, defaults disabled, custody documented, and evidence provided.

Audit it later as well. A reader added years afterwards by a different contractor is a common route back to a default configuration.

Whichever the site's credential is - and ideally more than one, so a later change of credential does not mean a change of reader.

Several distinct contactless card families operate at 13.56 MHz. They share the radio layer and differ completely above it.

A reader that supports only one family locks the site into that credential for the life of the hardware.

Multi-family readers also carry the legacy proximity technology, which is what makes a phased migration possible.

Check that support means full authenticated support rather than merely reading the card's serial number. Reading the serial number of a secure card is functionally the same as using a proximity card, and it is a surprisingly common misconfiguration.

Confirm the reader can be reconfigured in the field, not just at the factory.

No. The serial number is transmitted without authentication and can be copied, so using it discards the security the card was bought for.

Every contactless card announces an identifier during the initial handshake, before any authentication takes place.

It is tempting to use it because it works with any card and needs no key management at all. That convenience is exactly the problem.

Cards and emulation devices that present an arbitrary identifier are readily available.

The correct configuration reads an authenticated data element from a protected area of the card, which requires the keys and cannot be spoofed.

If a proposal for a smart card system does not mention keys anywhere, this is usually what is being offered.

Yes - separate key-protected areas on the card hold independent applications, and that shared use is often what justifies the cost.

Each application has its own keys, so the catering system cannot read the access application and vice versa.

Print release and cashless payment are the usual additions and both remove a separate card from people's pockets.

Logical access - using the card to log into a computer - is the highest value and has the strictest key management requirements.

The governance is the hard part: each application has an owner, and coordinating key custody across departments takes longer than the technical work.

Decide the intended applications before the first card order. Retrofitting one means getting keys onto cards that are already in people's pockets, which is considerably harder than encoding them at issue.

The wiring is the same, but a supervised encrypted reader-to-controller protocol should be used - otherwise the security stops at the reader.

A smart card reader can be wired over the legacy one-way interface, and many are.

That configuration authenticates the card to the reader and then sends the result down an unencrypted, unsupervised pair to the controller, where it can be captured or injected.

It is a common and serious oversight: the expensive part of the upgrade is undone by the cheapest part of the installation.

Specify readers and controllers that support the modern supervised protocol, and confirm at commissioning that encryption is actually enabled rather than available.

The cable itself is ordinary shielded multicore in both cases, so this is a configuration decision rather than an infrastructure one.