Key Fob, Card or Phone? Choosing Credentials for a Co-op or Condo

Boards usually treat the credential as a detail: the small thing you pick after choosing the panel and the reader. It is the opposite. The credential is the security boundary, and if it can be copied in a supermarket, nothing behind it matters.

There are three real choices for a New York residential building, and they differ far more in administration than in hardware. Here is what each one is, what it costs over a five-year hold, and how it behaves on the day something goes wrong.

125 kHz proximity: what your fob probably is

If your building has been using the same fobs since before roughly 2015, and the reader is a plain rectangle with one LED, you are almost certainly on 125 kHz proximity: HID ProxCard II, Indala, AWID, or an EM4100 clone.

A 125 kHz credential transmits a fixed facility code and card number in the clear. There is no encryption and no mutual authentication. The reader asks, the fob answers, and anything that hears the answer can repeat it. That is not a weakness in a particular product. It is the whole design, and it dates from the 1980s.

What that means in practice today:

• A handheld duplicator costs about $20 to $30 and copies a fob in roughly fifteen seconds: about five seconds to read and a few more to write to a blank.
• Long-range harvesters cost under $500, fit in a backpack, and read a credential through a coat pocket or a handbag from several feet away. The legitimate read range is under four inches; a purpose-built reader is not limited to that.
• Retail kiosks now duplicate them. Consumer key-copying machines in supermarket chains will clone a 125 kHz fob for a few dollars, which means a resident can hand out copies to a contractor, an ex-partner or a subtenant without anyone in the building knowing.

We are not telling you to rip out a working system tomorrow. We are telling you that if the board’s stated reason for the fob system is controlling who has access, 125 kHz no longer delivers that, and any budget planning for the next five years should assume replacement.

13.56 MHz smart cards: what “encrypted” does and does not mean

The modern answer is a 13.56 MHz smart credential with AES-128 and mutual authentication: the card and the reader each prove they hold the right key before any data moves, and the exchange changes every time, so recording it gains an attacker nothing.

The credentials worth naming: MIFARE DESFire EV3 (AES-128, and the only mainstream card credential carrying Common Criteria EAL5+ certification), HID iCLASS SE, and HID Seos. Any of the three is a genuine step change from proximity.

Now the honesty that most vendors skip, because “13.56 MHz” on its own is not a security claim:

• MIFARE Classic is 13.56 MHz and is broken. Its Crypto1 cipher has been defeated by published key-recovery attacks for years. A building sold “smart cards” that turn out to be MIFARE Classic has bought very little.
• Original iCLASS, not iCLASS SE, had its proprietary crypto publicly compromised in 2010. The product line continued under the same family name, which causes real confusion when boards read old spec sheets.
• Default keys are the commonest failure of all. A large share of deployed DESFire and NFC installations are still running the manufacturer’s factory keys, which are public. The chip is fine. Nobody changed the lock.

So the question to ask a bidder is not “is it encrypted?” It is: which chip, which key set, who generated the site key, and where is it stored? If they cannot answer that in one sentence, they have not done it before.

Mobile and Bluetooth credentials

A mobile credential lives in an app or in the phone’s wallet and reaches the reader over Bluetooth Low Energy or NFC. Both work; they behave differently.

BLE has range (several feet), which enables wave-to-unlock and hands-free entry with an armful of groceries, and which is exactly why it needs to be tuned. Set it too generous in a small vestibule and the door unlocks for a resident walking past on the sidewalk. NFC requires a deliberate tap at an inch or two, which is generally the more secure behavior for badge emulation, but on iPhone it is only available through Apple Wallet; Android supports both natively.

Wallet-based credentials are the version residents actually like, because the phone does not need to be unlocked and the app does not need to be open. They require explicit reader support: Apple VAS and ECP2 for Apple Wallet, Google Smart Tap for Google Wallet. Readers such as the HID Signo line ship supporting those alongside MIFARE, DESFire and legacy prox, which is what makes a staged migration possible.

The migration path we recommend where an old system is being replaced: install multi-technology readers that read both legacy prox and the new encrypted credential, run both for one re-badging cycle so residents change over at their own pace, then disable the 125 kHz side on a fixed date. That last step is the one buildings skip, and skipping it means you paid for encryption and kept the vulnerability.

What each actually costs

These are typical market figures for New York work in 2026, subject to survey. Credential pricing in particular moves with volume and vendor.

	125 kHz prox	13.56 MHz smart card	Mobile / BLE
Per credential	$2 to $5	$5 to $12	$0.35 to $0.75 per pass on some platforms; others bundle by user count
Replacement for a lost one	Cheap, but see below	Same as new	Reissue in the portal, no hardware
Recurring software	Usually none on an old on-premise panel	None to modest	Multifamily platforms commonly bill per unit, roughly $4.50 to $6.75 per unit per month
Cost per user, per year	Near zero after install	Near zero after install	Roughly $55 to $80 per unit per year at those rates
What you get for the money	An access list nobody can trust	A credential that cannot be cloned in a parking lot	Instant issue and revoke, an audit trail, no truck roll

The row that decides most board votes is the last two together. On a 100-unit building, a cloud multifamily platform at $5.50 per unit per month is about $6,600 a year, forever. That is real money and it should be presented as real money. What it buys is the elimination of a category of work that a managing agent currently absorbs invisibly, which is the next section.

The lost-credential workflow is the real test

Ask a bidder to walk you through what happens at 7 p.m. on a Friday when a resident calls to say their fob was stolen with their bag.

On a 125 kHz system with unassigned fobs, meaning the building bought a box of 200 and handed them out without recording which number went to which apartment, there is no answer. You cannot revoke a credential you cannot identify. The only real remedy is to re-badge the building, which means new credentials for every resident, a coordinated cutover, and weeks of the super handing out fobs to people who are never home.

On any system with per-credential enrollment, you look up the resident, void that credential number, and the door forgets it. Two minutes. This is not a technology difference. It is a record-keeping difference, and it is available on a thirty-year-old panel if somebody kept the list.

On a mobile system, the credential is tied to an identity rather than an object, so revocation is immediate and the resident is reissued without anyone physically meeting.

The lesson boards take from this is usually the right one: the credential technology matters, but the enrollment discipline matters as much. We will not commission an access system without a populated user list, because a building that cannot say who holds credential 0143 does not control its front door regardless of what the reader supports.

What happens when a resident sells the apartment

This is where co-ops and condos quietly lose control, and it happens the same way every time.

At closing, the seller hands the buyer the apartment keys and, informally, the building fobs. Nobody tells the managing agent, because nobody thinks of the fob as building property. Six months later the seller still has a working credential, so does whoever they lent one to during the move, and the building’s access list has quietly drifted from reality.

The fix is procedural and belongs in the house rules, not in the hardware. Credentials are issued to a person and a unit and are surrendered at closing or move-out; the transfer agent or the closing checklist includes deactivation; the managing agent issues the new resident’s credentials directly rather than letting them inherit. What technology changes is only how expensive that procedure is to enforce. On a mobile or cloud system it is a single portal action taken from an email. On unassigned prox fobs it is unenforceable, which is why it never gets enforced.

One point to raise with counsel before enabling anything that logs residents: New York City has a tenant data privacy law covering buildings using smart-access systems, broadly requiring written tenant consent, limiting collection to what is necessary, and requiring access records to be destroyed on a short clock. It is not a reason to avoid modern systems. It is a reason to configure the retention setting deliberately rather than leave it at the vendor’s default.

Vendor lock-in, and who holds the key

Two different traps get called “lock-in,” and only one of them is really about credentials.

Proprietary credential formats. Some manufacturers program cards in a format only they can supply, so re-ordering credentials means re-ordering from them, at their price, forever. The consultative question is simple: can I buy compatible credentials from a second source, and if the manufacturer discontinues this line, what happens to my 300 existing cards?

Who holds the site key. With encrypted credentials, whoever holds the key controls whether a different contractor can ever program a card for your building. If the integrator generated the key and kept it, you have not bought a security system, you have rented one. Ask for the key to be generated for your building, held by you, and documented in the handover pack.

Closed hardware ecosystems. Separately, some cloud platforms only work with their own controllers and readers, so changing platforms means replacing every piece of hardware at the door. Others are deliberately vendor-neutral, and open-architecture controller boards (the HID Mercury LP-series boards sit inside a surprising number of differently-branded systems) let you change head-end software while keeping the panels. That is worth real money at year seven and costs nothing at year one.

The wire behind the reader can undo your credential choice

You can specify DESFire EV3 with a properly managed site key and still be trivially attacked, if the reader talks to the controller over Wiegand.

Wiegand is one-way, unencrypted and unsupervised. It carries the card number as a plaintext pulse train on two data conductors. A small device wired behind the reader, the classic Wiegand tap, captures every credential presented and can replay them, and the panel has no way to know it is there. The reader has done its cryptography perfectly and then announced the answer in clear text on a wire anyone with a screwdriver can reach.

OSDP is the fix and it is now the professional default. It runs over an RS-485 twisted pair, is bidirectional, and its Secure Channel adds AES-128 session encryption between panel and reader. It also supervises: the panel knows if a reader goes offline, is tampered with, or is swapped for a different one. Practical differences worth knowing: OSDP reaches roughly 4,000 feet against Wiegand’s 500, and multiple readers can share one daisy-chained cable instead of each needing a home run to the panel, which in a pre-war building with no spare pathway is often the deciding factor.

The step that gets skipped in the field: OSDP devices ship with a default install key, and they must be moved to a unique Secure Channel Base Key at commissioning. Ask, in writing, whether that was done.

Where phone credentials actually fail

We install mobile systems and recommend them often. These are their real failure modes, and every one of them arrives at the lobby door at an inconvenient time.

• Dead battery. The phone is the credential. Some implementations keep working briefly in the phone’s low-power reserve; many do not.
• New phone. Credential migration is a per-resident support event. On a 100-unit building assume a steady trickle of them, forever.
• Residents without smartphones. Older shareholders, children, and anyone who simply does not want an app. A building that goes mobile-only creates a group of people who cannot get into their own home.
• Guests, aides, dog walkers and contractors. Time-bounded PINs or visitor passes handle this well, but only if somebody sets them up. The default is a resident lending out a credential.
• Connectivity. Reputable systems cache the access list at the controller and keep enforcing it offline, but new credentials, revocations and remote unlock stop working until the link returns. Get that behavior in writing, and put a UPS on the network closet and a battery at the door.

The conclusion we reach on almost every building: mobile as the primary credential, an encrypted card or fob as the guaranteed fallback, and a documented mechanical override. Mobile-only is a design decision that should be made deliberately, not by default.

The administration burden nobody prices

Take a 200-unit building with typical residential turnover of around 15% a year. That is roughly 30 move-outs and 30 move-ins annually. At two credentials per household, that is about 120 credential events a year before you count lost fobs, contractors, brokers during a sale, and aides.

On an old panel, each of those is a physical event: someone meets the resident, programs a fob at the panel, updates a spreadsheet if you are lucky. On a cloud platform it is a portal entry the managing agent makes from their desk, and the audit trail writes itself. That difference, not the encryption, is what most managing agents are actually buying, and it is why per-unit subscription pricing tends to survive the board vote once somebody counts the hours honestly.

A recommendation framework

Building	Sensible credential	Why
Under 20 units, no staff, tight budget	Encrypted 13.56 MHz cards or fobs, per-credential enrollment, on-premise panel	No recurring cost, and the administration volume is small enough for a spreadsheet to work
20 to 75 units, part-time super, managing agent	Mobile primary with encrypted card fallback, cloud platform	Turnover volume already justifies remote administration; the per-unit fee is modest at this size
75 to 250 units, full staff, high turnover	Mobile primary, encrypted card fallback, cloud with directory sync and per-unit billing	Roughly 100+ credential events a year; the labor saved exceeds the subscription
Any building with an existing 125 kHz system and no budget this year	Multi-technology readers now, dual-run, disable prox on a fixed date	Spreads the cost across two capital cycles without leaving the vulnerability open indefinitely
Mixed-use with commercial tenants	Separate credential groups and separate directories	Commercial and residential populations must not be able to admit each other

If you already have a proposal in front of the board, the four questions that will tell you most about it are: which chip is the credential, who holds the site key, is the reader wired OSDP with a unique secure-channel key, and what is the five-year subscription total. If a bidder is uncomfortable answering any of those in writing, that is the answer.