Card and PIN access control
How Does an RFID Card Access Control System Work?
A card held near a reader transfers a number by radio. A controller behind the door checks that number against stored permissions and a time schedule, releases the lock if the rules allow it, and writes a record of what happened. The same read can be kept as an attendance punch. This page explains the whole chain in detail: the card technologies and where their security actually lives, how the reader talks to the controller, how the door hardware behaves when power is lost, and where a card and PIN system is genuinely the right design rather than a fallback.
RFID card access control in one paragraph
An RFID card access control system is a set of readers, controllers and locks that decides who may pass through a door and records every attempt. A card held near a reader transfers an identifier by radio. The reader passes that identifier to a controller, which checks it against stored permissions and a time schedule, releases the lock if the rules allow it, and writes an event. The same read can be recorded as an attendance punch, so one credential serves both entry control and timekeeping. The decision is taken at the door rather than at a server, which is why the doors keep working when the network does not.
- A token, not a person, so the system authenticates the card rather than identifying its holder
- Decision at the panel, with the cardholder table and schedules held locally
- Card technology decides security, from fixed-number proximity to encrypted mutual authentication
- Two jobs from one read, door release and a timestamped attendance event
What is an RFID card and PIN access control system?
Unlike the biometric terminals in the rest of this cluster, a card system does not identify a person. It authenticates a token. That single sentence explains both its strengths and its weaknesses, and everything else on this page follows from it. A card is instantly issuable, instantly revocable, works for every human being regardless of hand or face condition, and can be handed to somebody else.
A PIN behaves the same way. It is something the holder knows rather than something they carry, but it is equally transferable. Combining the two raises the bar, because an impostor now needs both the card and the number, but neither factor is tied to a body. This is the baseline that biometric attendance systems are measured against, and understanding it properly is the only way to judge whether biometrics are warranted at a given door.
How an RFID card access control system works: the short answer
The system works in five stages. The reader radiates a field that powers the card, which has no battery of its own. The card responds with an identifier, either a fixed serial number or, on a secure card, an encrypted payload released only after both sides have authenticated each other. The reader passes that identifier to the controller over Wiegand or OSDP. The controller decides, comparing the credential against its cardholder table, the access level attached to that door, and the time schedule in force. On an allow decision it actuates the lock relay for a configured release time and writes a transaction containing the credential, the door, the time and the result.
Every one of those stages happens at the door. The controller holds its own copy of the permission database, so the decision does not travel to a server and back. Nothing about the sequence depends on the building's internet connection being up, which is the single most important practical property of the architecture and the reason it is described in detail below.
A denied read is as important as an allowed one. The controller records the credential, the door and the reason, which is how an audit trail distinguishes between a card that was never issued, a card that was issued but revoked, and a valid card presented outside its permitted hours. Software then turns those transactions into reports, and where the same reads are being used for timekeeping, hands them to attendance software and applications for shift and policy processing.
From card presentation to door release, step by step
| Step | What happens | How it works |
|---|---|---|
| 1 | Credential is issued | A card is encoded and linked to a cardholder record. The record carries an access level naming which doors and which time schedules apply, and a validity window with a start and an expiry date. |
| 2 | Card enters the reader field | The reader continuously radiates an alternating field. The card's antenna coil picks up energy by inductive coupling and powers the chip. No battery, no contact, no moving parts. |
| 3 | Card and reader exchange data | A proximity card simply transmits its stored number. A secure smart card first performs mutual authentication, and only then releases the protected data held in an application on the chip. |
| 4 | PIN is entered, where configured | On a keypad reader in card plus PIN mode, the controller waits for a PIN within a short timeout and treats the pair as a single credential presentation. |
| 5 | Reader sends the credential to the controller | Over Wiegand as a one-way pulse train, or over OSDP on RS-485 as an addressed, acknowledged message that can be encrypted end to end. |
| 6 | Controller evaluates the request | Is the credential known and active, is this door in its access level, is the current time inside the permitted schedule, are anti-passback or interlock conditions satisfied, is the door in a lockdown state. |
| 7 | Decision is made locally | The controller answers from its own memory. A server is not consulted, which is why doors keep working through a network outage. |
| 8 | Lock relay is actuated | The relay energises or de-energises depending on lock type, for a release time typically set between three and ten seconds according to the door and the users. |
| 9 | Door is monitored | A door position switch confirms the door actually opened and closed. Held-open and forced-open alarms are generated from this input, not from the card read. |
| 10 | Exit is handled | A request to exit device releases the lock from the secure side, or a second reader on the inside captures an exit read for anti-passback and attendance direction. |
| 11 | Transaction is written | Credential, cardholder, door, reader, time, direction and result are stored in the controller's event buffer and uploaded to the server when the link is available. |
| 12 | Software applies meaning | Access reports, occupancy and muster lists for access control. Shift resolution, late marks, overtime and leave reconciliation where the same reads feed attendance. |
125 kHz proximity versus 13.56 MHz smart cards
The frequency a card operates at determines how it couples to the reader, how much data it can carry and, indirectly, what security it is capable of. Two families dominate installed sites in India, and they are not interchangeable: a reader built for one will not read the other unless it is a dual-frequency model.
125 kHz proximity: how it works and what it does not do
Low frequency proximity cards, often referred to by the generic term prox, work by inductive coupling at 125 kHz. The card contains a coil and a small chip holding a fixed number, typically 26 to 37 bits. When energised, it transmits that number repeatedly for as long as it stays in the field. There is no processor on the card, no memory to write to and no cryptography of any kind.
That simplicity has real advantages. The low frequency penetrates moisture and is comparatively tolerant of being carried in a wallet against other cards, and read range is forgiving, which matters for gloved hands on a plant floor. The disadvantage is absolute: a card that transmits a fixed number on demand to anything that asks can be captured and replayed by a device small enough to sit in a pocket. The number is an identifier, not a secret.
13.56 MHz smart cards: a conversation, not a broadcast
High frequency cards following ISO/IEC 14443 carry a microprocessor or a structured memory organised into applications and files. Instead of broadcasting a number, the card and reader run a protocol. The reader selects the card by its anti-collision identifier, selects an application, and then has to prove it holds the correct key before the card will release anything meaningful.
Because the card has processing capability, it can hold several independent applications under separate keys. One site commonly runs access control, canteen entitlement and a library or asset application on the same physical card, with the access control key known only to the access system. Data rates are high enough that the whole exchange still completes in a fraction of a second.
Why reading the serial number throws the security away
This is the single most common misconfiguration in the field, and it deserves naming plainly. Every ISO/IEC 14443 card has a unique identifier, the UID or CSN, used only for anti-collision so that two cards in the field can be told apart. It is transmitted in the clear, before any authentication, by design.
A reader can be configured to use that UID as the credential number. Doing so is quick, needs no key management and works with any card from any supplier. It also reduces an encrypted smart card to exactly the same security posture as a 125 kHz prox card, because the value being used is a fixed number sent unprotected. A site that has paid attention to card technology and then reads the UID has gained nothing. If a project specifies secure smart cards, the commissioning record should state which sector or application and which key diversification scheme the readers are configured for.
| Property | 125 kHz proximity | 13.56 MHz read by UID | 13.56 MHz with secure application |
|---|---|---|---|
| What the reader gets | A fixed number stored at manufacture | The anti-collision serial number | Protected data released after mutual authentication |
| Cryptography | None | Present on the card but unused | AES or 3DES depending on card family |
| Replay resistance | None | None | Session keys and random challenges resist replay |
| Key management needed | No | No | Yes, and this is the real work of deployment |
| Multi-application | No | No | Yes, separate applications under separate keys |
| Typical fit | Low-consequence internal doors, legacy estates, visitor and contractor passes with short validity | Not a deliberate design choice; usually an oversight | Perimeter, server rooms, cash handling, stores and any door where the consequence of entry is material |
MIFARE Classic, DESFire and mutual authentication
Within the 13.56 MHz family, the card product chosen makes more difference than the frequency did. Two names dominate specifications in India, and the gap between them is substantial.
Why MIFARE Classic is considered cloneable
MIFARE Classic organises memory into sectors, each protected by two keys, and uses a proprietary stream cipher called CRYPTO1 with a 48-bit key. Academic cryptanalysis published from 2008 onwards demonstrated structural weaknesses in CRYPTO1 and in the card's random number generation, and practical attacks that recover sector keys followed. Tooling to exploit them is now widely circulated and runs on commodity hardware.
The honest position is that MIFARE Classic should be treated as an identifier rather than a secret-bearing credential, and that any door where unauthorised entry has real consequences should not depend on it alone. Enormous numbers of Classic cards remain in service in Indian buildings, and they are not useless: they still support revocation, still produce an audit trail and still stop casual entry. What they do not do is resist a determined attacker with modest equipment. A site that knows this and places Classic on internal corridor doors while putting a stronger credential or a biometric on the server room has made a defensible decision. A site that does not know it has made an accidental one.
What mutual authentication actually proves
MIFARE DESFire, in its EV2 and EV3 generations, replaces the proprietary cipher with AES-128 and runs a three-pass mutual authentication before any application data moves. The sequence is worth understanding because it explains what cloning protection means in practice.
The reader asks to authenticate to an application. The card generates a random number, encrypts it with the application key and sends it. The reader, which must hold the same key, decrypts it, generates its own random number, and returns both values encrypted. The card verifies that its own random number came back intact, which proves the reader holds the key. The reader verifies the card's response, which proves the card holds it too. Both sides then derive a session key from the two random numbers, and the rest of the exchange runs encrypted under that session key.
Two properties follow. Neither side ever transmits the key. And because the session key is derived from fresh random numbers each time, a recording of one transaction cannot be replayed to open the door again. That is the difference between a card that announces a number and a card that proves it holds a secret.
Diversified keys and why one compromised card is not the whole site
A deployment that writes the same application key to every card has created a single point of failure: extract it once and every card on site can be produced. Key diversification solves this by deriving each card's key from a master key combined with that card's unique identifier, so every card carries a different key while readers can still compute the right one on the fly.
The practical consequence is containment. A compromised card yields that card's key and nothing else. It also means the master key becomes the asset that matters, which moves the security problem from the cards to the handling of the key material in the encoder and the readers. Any specification that names DESFire without naming the diversification scheme has left the most important detail unstated.
Wiegand versus OSDP: how the reader talks to the controller
Card security protects the exchange between the card and the reader. It does nothing about the cable between the reader and the controller, and that cable is where a large share of real attacks on access control systems happen. It is also where the installed base in India is furthest behind current practice.
Wiegand: one direction, no supervision, no encryption
The Wiegand interface dates from the 1980s and has been the default reader connection ever since. It uses two data lines, DATA0 and DATA1, pulsed to transmit a bit stream, most commonly 26 bits comprising a facility code, a card number and parity. It is one-way: the reader talks, the controller listens, and there is no acknowledgement, no addressing and no encryption.
Three consequences matter. First, the credential travels in the clear, so anyone who reaches the cable behind the reader can record card numbers and later inject them, opening the door without presenting any card at all. Second, the connection is unsupervised: if the cable is cut or the reader is removed, the controller does not know, because silence on a Wiegand line is indistinguishable from nobody presenting a card. Third, the protocol is effectively home-run, which means one cable per reader back to the controller and a practical distance limit around 150 metres.
OSDP and Secure Channel
The Open Supervised Device Protocol, standardised by the Security Industry Association and published as SIA OSDP and as IEC 60839-11-5, replaces all three weaknesses. It runs over RS-485, which is bidirectional and multi-drop, so several readers share one twisted pair and each has an address. The controller polls each reader continuously, so a missing or disconnected reader raises a tamper or communication-loss event within seconds rather than going unnoticed.
OSDP Secure Channel adds AES-128 encryption and message authentication between reader and controller, so recorded traffic cannot be replayed and injected messages are rejected. Because the link is bidirectional, the controller can also drive reader behaviour: LED colour, buzzer, display text, biometric template push on combination readers, and firmware update without a site visit to each door. RS-485 also carries much further than Wiegand, which changes what is possible on a spread-out campus.
Migration in an existing building
Most Indian buildings running access control today are wired for Wiegand, and rewiring an occupied floor is disruptive. Two routes exist. Many current readers support both protocols and can be switched in configuration, so if the controller supports OSDP the change may be a settings change rather than a cabling change. Where cabling must change, OSDP's multi-drop topology often needs less new cable than the original installation did, because one run can serve several doors in a corridor.
| Property | Wiegand | OSDP with Secure Channel |
|---|---|---|
| Direction | Reader to controller only | Bidirectional |
| Encryption | None, credential sent in the clear | AES-128 with message authentication |
| Supervision | None, a cut cable is silent | Continuous polling, loss detected in seconds |
| Topology | One home run per reader | Multi-drop on RS-485, addressed readers |
| Typical distance | Around 150 metres | Up to roughly 1200 metres on a compliant RS-485 run |
| Reader management | Local configuration, site visit per reader | Remote configuration, firmware update and LED or audio control |
| Credential length | Fixed formats, commonly 26 bits | Variable, suits long secure credentials |
Controller architecture and where the access decision is made
The controller is the part of the system that most buyers never see and that determines almost everything about how the installation behaves under stress. It is a processor with non-volatile memory, relay outputs, supervised inputs, reader ports and a network interface, usually mounted in a metal enclosure on the secure side of the doors it serves. Controllers are sized by door count, commonly one, two or four doors, with larger panels aggregating more.
The decisive design property is that the controller stores the cardholder table, the access levels, the time schedules and the holiday calendar locally. The decision is taken in the panel. The server distributes changes to the panels and collects transactions from them, but it is not in the path of a door opening. A failed server, a failed switch or a severed uplink delays reporting and delays the propagation of new cards; it does not lock anybody out and it does not let anybody in.
Panel memory therefore sets two limits worth checking at design stage: how many cardholders a controller can hold, and how many transactions it can buffer before it starts overwriting. On a site with intermittent connectivity, buffer depth is the number that matters, because it decides how long an outage can run before events are lost. A busy main gate generates far more transactions per day than an internal office door, and the two should not be sized the same way.
Network-attached controllers are IT assets and should be treated as such. They belong on a segmented network or VLAN, with default credentials changed at commissioning and firmware kept current. This is routinely skipped, and a controller sitting on the flat office network with factory credentials undermines every decision made about card technology upstream of it. The same reasoning applies when controllers are integrated with access control systems spanning several buildings.
Door hardware, request to exit and door monitoring
A door under access control normally carries four devices beyond the reader. The lock holds the door shut. A request to exit device releases it from the inside. A door position switch reports whether the leaf is open or closed. And a power supply, usually with battery backup, feeds all of them.
Request to exit, written REX, exists because of a principle that is not negotiable: people must be able to leave without presenting a credential. A push button beside the door, a passive infrared sensor above it, or a microswitch in the panic bar or door handle tells the controller that an exit is legitimate. Two things happen on a REX signal. The lock releases if the lock type requires power to hold. And the controller suppresses the door-forced alarm for the duration, so a normal exit is not reported as a break-in. Where exits must also be recorded, for anti-passback or for attendance direction, a second reader is fitted on the inside face and REX is retained alongside it as the safety path, not as a substitute for it.
The door position switch is what makes monitoring real. Without it the system knows a card was read but not whether the door opened, whether it closed again, or whether it was propped. With it the controller generates two distinct alarms. Door forced open means the switch reported open with no valid read and no REX. Door held open means the switch stayed open beyond a configured time after a valid entry, which is how propping is caught. These alarms are the most useful output of an access control system in day to day operation, and they are frequently not commissioned because the switch was never wired.
Lock selection follows the door. An electromagnetic lock holds a plate against an armature and suits glazed and aluminium doors. An electric strike replaces the keep and suits timber doors with an existing latch. Drop bolts and electric mortise locks cover other cases. Each has a different behaviour when power is removed, which is the subject of the next section and is a life-safety matter rather than a preference. On entrance lanes the same controller logic drives turnstile gates and entrance control hardware instead of a door lock, and our guide to how a turnstile system works covers the pedestrian lane in detail.
Fail-safe versus fail-secure and behaviour on fire alarm
These two terms describe what a lock does when it loses power, and they are often used loosely in conversation when the distinction is the most consequential one in the whole installation.
Fail-safe locks require power to stay locked. Remove power and the door is free to open. An electromagnetic lock is inherently fail-safe: no current, no magnetic force, no hold. Fail-secure locks require power to release and stay locked when power is removed. A standard electric strike is usually fail-secure. The names describe which failure the design protects against: fail-safe protects life, fail-secure protects property.
On a door in an escape route the behaviour required is fail-safe, and the release must be achieved by removing power through a path that does not depend on the access control system working. In practice the fire alarm panel's voltage-free contact interrupts the power to the maglocks on that escape route directly, so the doors free themselves whether or not the controllers, the server or the network are alive. An access control system that releases escape doors only through its own software logic has made life safety conditional on a computer. A green break-glass unit on the secure side wired in the same series path gives a manual release that is equally independent.
Fail-secure is appropriate where the door is not an escape route and where loss of power must not grant entry: a strong room, a stores cage, a server room with alternative egress. Egress from inside such a space must still be achievable mechanically, which is usually solved with a lock whose inside handle always retracts the latch regardless of the electrical state.
The governing requirements come from the National Building Code of India and the fire regulations of the state in question, and they vary by occupancy class, by building height and by the local fire service's practice. Hill-state projects in Himachal Pradesh and Uttarakhand frequently involve older structures and constrained stairwells where the escape route determination is not obvious from the drawings. The door-by-door schedule of fail-safe and fail-secure should be agreed with the fire consultant and the authority having jurisdiction, recorded in writing, and tested at handover by triggering the alarm and walking the route. Current requirements must be confirmed for the specific project rather than assumed from another site.
Card plus PIN as two-factor at the door
A keypad reader allows a door to require something held and something known. The controller treats the pair as one presentation: card first, then PIN within a short timeout, and a failure of either is a denial. The security gain is real, because a lifted or cloned card is no longer sufficient on its own.
The gain has limits that should be stated. A PIN is shareable, and in practice it is shared, particularly where a small team covers a store or a control room around the clock. PINs are also observable: a keypad in a corridor with people queueing behind is not a private input. Mitigations exist and are worth configuring. Scrambling keypads randomise digit positions on each use. Duress PIN support lets a user enter a modified code that opens the door and silently raises an alarm. A short PIN length policy, individual PINs rather than a door PIN, and a lockout after a small number of failed attempts all reduce the attack surface.
Most sites do not apply card plus PIN everywhere. It is applied by door and by time: a perimeter door might take card only during the working day and card plus PIN outside those hours, while a cash room takes card plus PIN at all times. That per-door, per-schedule configuration is the same mechanism that later allows a biometric to be added as a third factor on the few doors that justify it, which is where multi-modal biometric terminals fit into an existing card installation.
Card and PIN for attendance, not only access control
The same read that opens a door can record a timestamped attendance event, and in many Indian installations that is exactly how the system is used. A reader at the main gate in entry and exit mode produces in and out punches; software resolves them against shifts, applies grace periods and late marks, calculates overtime and reconciles leave, then exports payable days to HRMS and payroll software. From the software's point of view a card punch and a biometric punch are the same kind of record, differing only in the verification method field.
Card-based attendance has specific strengths. Throughput is constant regardless of how many people are enrolled, because there is no matching database to search, which makes it predictable at a gate where several hundred people arrive in a narrow window. Enrolment is instantaneous: a contractor reporting at 7 am can be issued a card with a validity window ending on the contract date and be productive the same morning. And it works for every person, with no equivalent of failure to enrol.
Its weakness is the one named above, and it is decisive for payroll. Attendance data derived from cards alone is only as reliable as the workforce's willingness not to share them. Many sites resolve this with a split design that respects both realities: cards for door access throughout the site and for short-engagement contractors and visitors, biometrics on the attendance terminals that feed payroll, and both streams landing in one database. That is the design pattern behind combined attendance and access control deployments, and it is usually a better answer than forcing one credential type across every use.
Where a card and PIN system is the right answer
This cluster covers five biometric modalities, and it would be easy to treat cards as the thing you settle for. That is not an accurate reading of the engineering. There are situations where a card and PIN system is the correct design and a biometric would be the wrong one.
Population churn is the clearest case. A logistics hub or a project site cycling through contract labour weekly cannot sustain a biometric enrolment process for people who will be gone in ten days. Card issue and revocation are administrative actions taking seconds. Visitors are the same problem in miniature, which is why a visitor management system issues a temporary card with an expiry rather than enrolling a biometric for a two-hour visit.
Throughput at a constrained point is the second. Card reads are constant-time, so a lane's capacity is set by the mechanics of the turnstile and by walking speed, not by the size of the enrolled population. Where tens of thousands of credentials exist and people must pass quickly, this predictability matters.
Environmental and occupational reality is the third. Hands in heavy gloves, workers whose finger ridges are genuinely worn by their trade, faces behind protective equipment, sterile and food-handling areas with no-touch policies: each of these defeats specific biometric methods. A card in a pocket works regardless. And there are doors where the consequence of entry simply does not justify the data protection obligations that come with collecting biometric information from every person who passes.
| Situation | Card and PIN | Biometric warranted |
|---|---|---|
| High workforce churn, contractors, visitors | Strong fit. Issue and revoke in seconds, validity windows by contract date | Enrolment effort rarely justified for short engagements |
| Attendance feeding payroll for permanent staff | Weak. Sharing cannot be prevented by any card technology | Yes. A credential tied to the person is the only reliable answer, as with fingerprint attendance systems |
| High-volume gate at shift change | Strong fit. Constant-time reads, predictable lane capacity | Workable, but throughput must be designed around matching time |
| Gloved, masked or heavily protected users | Strong fit, works regardless of hand and face condition | Only where the modality tolerates it, such as iris recognition for gloved and protected users |
| Sterile and food-handling areas with no-touch policies | Strong fit, nothing is touched at the door | Contactless modalities only, such as how a palm vein scanner works or how a face recognition terminal works |
| Server room, cash handling, stores | Workable with a secure credential plus PIN | Preferred where the consequence of a shared credential is serious |
| Low-consequence internal doors | Strong fit. Proportionate, and avoids collecting biometric data unnecessarily | Generally disproportionate |
| Typical failure mode | Shared, lost or copied credential | Failure to enrol or to match for a proportion of users |
Choosing between these per door, rather than adopting one credential for a whole site, is the method set out in the guide to choosing a biometric attendance and access control system. For the wider category of devices that record a punch, see how an attendance machine works.
Credential lifecycle, data protection and record keeping
A card system holds less sensitive data than a biometric one, and that is a genuine point in its favour. It still holds personal data. A cardholder record ties a name, an employee number and often a photograph and a department to a stream of timestamped movements through a building. Under the Digital Personal Data Protection Act 2023 that is personal data, and the obligations that follow apply to purpose limitation, retention and the handling of access requests. The Act's requirements, and their application to a specific organisation, must be confirmed for the project; nothing here should be read as a statement of compliance on any party's behalf.
Lifecycle discipline is where most sites are weak. Cards issued to people who left two years ago, still active in the panel database, are common findings in access audits. A defensible lifecycle has four points: issue against an authorised request with a recorded validity window; change the access level when the person changes role rather than accumulating permissions; deactivate on the day of exit as part of the exit checklist rather than on card return, because the card may never come back; and reconcile the active cardholder list against the HR active-employee list on a fixed schedule so discrepancies surface.
Where the same system also serves attendance, the records interact with the Factories Act 1948, state Shops and Establishments legislation, and the record keeping expected for payroll, EPFO and ESIC purposes. Retention periods are therefore set by what the organisation must be able to produce, not by what the system can store. Access movement data that serves no retention requirement should have a defined deletion schedule, and the system should be able to execute it. BIS and STQC certification and listing on the Government e Marketplace are relevant where the end client is a government body; again, current requirements should be confirmed with the client's procurement team for each project.
Operational controls complete the picture: role-based permissions deciding who can issue cards, change access levels, delete transactions or export reports, and an audit trail recording those administrative actions attributably. A system where any operator can quietly grant themselves access to a restricted door and delete the evidence has no meaningful security regardless of its card technology.
Indian site conditions: environment, power and connectivity
Card readers are simpler than biometric terminals and survive conditions that defeat optical sensors, but they are not immune to the environment. An outdoor reader at a gate needs a weather-rated enclosure, and on both seaboards salt-laden air attacks connector plating and PCB tracks, so sealed glands and periodic inspection of terminations matter more than they would inland. Dust on construction and mining sites is less of a problem for a reader than for a fingerprint platen, which is one of the practical reasons card credentials persist at site gates. Summer ambient above 45 C across the northern plains affects the controller enclosure more than the reader: a sealed metal panel in direct sun will exceed its rating, so panels belong indoors or in shaded, ventilated positions.
Power quality is the recurring Indian problem. Access control panels and locks should sit behind surge protection and UPS backing, sized to hold the system through the outage duration the site actually experiences. Battery backup at the panel is not optional on a fail-secure door, where loss of power leaves people unable to enter, nor on a maglock installation where the battery is what keeps the door locked. The battery is a consumable and needs a replacement schedule; a backup that has silently failed is worse than none, because the site believes it is protected.
Connectivity is handled by the architecture rather than worked around. Because the controller decides locally, a plant in a hill district of Himachal Pradesh or Uttarakhand with an intermittent link continues to admit and record normally while the link is down. Transactions queue in panel memory and upload when connectivity returns, so the central reports catch up rather than losing the period. The two things to size for are buffer depth against the longest realistic outage and the propagation delay on card deactivation, since a revoked card remains valid at an offline panel until the change reaches it. Sites in Tripura and other northeastern locations where links are less consistent should set that expectation explicitly with security staff, and a documented offline revocation procedure covering a physically collected card is worth having.
Mechanical conditions deserve a mention because they cause more call-outs than electronics. Monsoon humidity swells timber doors so they no longer close cleanly, which generates held-open alarms that get dismissed as faults until the real one is ignored too. Door closers fall out of adjustment. On glazed entrance doors, maglock armatures work loose from repeated slamming. A quarterly walk of every controlled door, checking that it closes and latches under its own closer, prevents most of this.
Installation, commissioning and maintenance
A card access installation is mostly a cabling and door-hardware exercise, and the quality of those two things determines how the system behaves for its whole life.
- Reader position. Mount on the latch side at a height reaching both standing and seated users, typically between 1.0 and 1.2 metres. Keep readers away from large metal surfaces and from each other; two 13.56 MHz readers mounted back to back through a partition will interfere.
- Cable discipline. Shielded cable for reader runs, earthed at one end only, routed clear of power cabling. On Wiegand installations, respect the distance limit rather than discovering it as intermittent misreads months later. On OSDP, terminate the RS-485 bus correctly and keep the topology a daisy chain rather than a star.
- Panel location. Secure side only, in a lockable enclosure with a tamper switch wired to a supervised input. A controller reachable from the unsecured side of the door it controls defeats the entire installation.
- Door hardware first. Confirm the door closes and latches reliably under its own closer before any electronics are fitted. Electrification does not fix a door that does not shut.
- Commission the inputs, not only the outputs. Test door forced, door held, REX suppression and tamper on every door. These are the alarms that are most often left unwired and that carry most of the operational value.
- Test the fire interface by triggering it. Activate the alarm and walk the escape route, confirming every maglock on it releases. Record the result. A desk check of the wiring diagram is not a test.
- Record the credential configuration. Which card family, which application or sector, which key diversification scheme, which bit format. This document is what allows the site to add readers or change supplier in three years without re-badging everyone.
- Ongoing checks. Reconcile active cardholders against HR records on a schedule. Verify panel clocks are synchronised, since a drifted clock corrupts both the audit trail and the attendance data. Confirm transactions are uploading after any network change. Replace standby batteries on a planned schedule. Keep controller and reader firmware current, and change default credentials on anything with a network interface.
RFID card access control: frequently asked questions
Does an RFID card access control system work without an internet connection?
Yes. The controller at the door holds its own copy of the cardholder list, access levels and time schedules, and makes the decision locally without consulting a server. Doors continue to open and events continue to be recorded during an outage, queued in panel memory and uploaded when the link returns. The two limits are buffer depth, which decides how long an outage can run before events are overwritten, and the delay before a newly revoked card stops working at that panel.
What is the difference between 125 kHz proximity cards and 13.56 MHz smart cards?
A 125 kHz proximity card holds a fixed number and transmits it to any reader that energises it, with no processor and no cryptography. A 13.56 MHz smart card carries a chip that runs a protocol, holds multiple applications under separate keys, and can require the reader to prove it holds the correct key before releasing data. The frequency difference matters less than that capability difference, which is what makes replay and cloning resistance possible.
Can an RFID access card be cloned?
It depends entirely on the card type and how the reader is configured. A 125 kHz proximity card can be copied with commodity hardware and brief proximity to the holder. MIFARE Classic has known cryptographic weaknesses and practical attack tooling exists. A DESFire card using AES mutual authentication with diversified keys resists cloning, because the key is never transmitted and each session uses fresh random values. A secure card read only by its serial number has the same exposure as a proximity card.
What is OSDP and why is it preferred over Wiegand?
OSDP is the Open Supervised Device Protocol, a bidirectional reader interface running over RS-485. Wiegand is one-way, unencrypted and unsupervised, so a credential can be captured from the cable and a cut wire is indistinguishable from silence. OSDP polls each reader continuously, detects disconnection within seconds, and with Secure Channel encrypts reader traffic with AES-128. It also allows several readers on one bus and remote reader configuration and firmware update.
What happens to the doors when the fire alarm goes off?
Doors on an escape route should be fail-safe, meaning they need power to stay locked and free themselves when power is removed. The correct arrangement interrupts power to those locks directly from a fire alarm contact, so release does not depend on the access control software, the controllers or the network being alive. A manual break-glass unit in the same path provides an independent release. The door-by-door schedule must be agreed with the fire consultant and the authority having jurisdiction for the specific building.
Is a card and PIN system secure enough for a main entrance?
It can be, provided the credential and the reader link are chosen deliberately. A secure smart card with mutual authentication and diversified keys, read over OSDP with Secure Channel, with PIN required outside working hours, is a defensible main entrance design. The same door running 125 kHz proximity cards over unsupervised Wiegand is not, regardless of what the software can do. The decision should be made door by door against the consequence of unauthorised entry.
What is buddy punching and can a card system prevent it?
Buddy punching is one employee presenting another person's credential so an absent colleague appears to have attended. No card technology prevents it, because the card is being presented willingly by its owner's choice. Adding a PIN does not help either, since the PIN is handed over with the card. Preventing it requires a credential tied to a body, which is why sites that keep card access control at the door frequently use biometric terminals for the attendance records that feed payroll.
What happens if an employee loses their access card?
The card is deactivated in the software and stops working as soon as that change reaches the controllers, which on a connected system is immediate. A replacement is encoded and issued in minutes against the same cardholder record, so the person's permissions and history are preserved. On a site with intermittent connectivity the deactivation reaches an offline panel only when the link returns, so a documented procedure for that situation is worth having.
Can the same card be used for attendance and door access?
Yes, and this is the normal arrangement. One read can release the door and write a timestamped attendance event at the same time. Software then applies shift, grace, overtime and leave rules to produce payable days, while access reports draw on the same transactions. Readers configured for entry and exit give directional punches. A secure smart card can also hold separate applications for canteen or other services under different keys.
What is request to exit and why does the door need it?
Request to exit, often shortened to REX, is a button, infrared sensor or handle microswitch on the secure side that lets a person leave without presenting a credential. It releases the lock where the lock type requires power to hold, and it suppresses the door-forced alarm so a normal exit is not reported as a break-in. It exists for safety and should remain in place even where an inside reader is fitted to capture exit reads for anti-passback or attendance direction.
When is a card and PIN system a better fit than a biometric system?
Where the population turns over quickly, because issue and revocation take seconds and enrolment is not required. Where throughput at a constrained lane must stay constant regardless of how many credentials exist. Where users wear gloves or protective equipment, or work in trades that wear down finger ridges. And on low-consequence internal doors, where collecting biometric data from everyone who passes would be disproportionate to what the door protects.
Planning a card access control or attendance deployment?
Tell us the doors involved, the card technology already on site, the reader protocol in the existing cabling and whether the same reads need to feed payroll, and our team will confirm what fits each point and what should change.
Talk to our team about a site surveyCall +91 95999 53923
This page explains how RFID card and PIN access control works as a technology class. Card security outcomes depend on the card family, the reader configuration and the key management in use at a specific site. Fail-safe and fail-secure behaviour on every door is a life-safety matter to be agreed with the fire consultant and the authority having jurisdiction. Statutory and certification requirements change and must be confirmed for each project. Specifications may change without notice; please consult us before ordering.
