Waarom toegangscontrole goede RFID-kaarten weigert

Een toegangscontrolesysteem kan een technisch perfecte RFID-kaart weigeren om redenen die niets met de kwaliteit van de kaart te maken hebben. Dat is precies wat veel inkopers moeilijk vinden om te accepteren. De kaart kan schoon, nieuw, correct gelamineerd en probleemloos uitleesbaar zijn op een desktop-encoder. Ze kan zelfs in een ander gebouw werken. Toch gebeurt er bij één deur, lift, tourniquet of parkeergate helemaal niets. De reader piept anders, de controller registreert een onbekende credential of de software meldt simpelweg dat toegang is geweigerd.

Daardoor ontstaat vaak de verkeerde discussie. De gebruiker wijst naar de kaartleverancier. De kaartleverancier zegt dat de kaart goed uitleesbaar is. De installateur zegt dat de reader werkt. Het softwareteam zegt dat de persoon geen rechten heeft. Iedereen kan deels gelijk hebben, terwijl de kaart aan de deur toch wordt geweigerd. Toegangscontrole is geen eenvoudige ja-of-nee situatie. Het is een keten van kaartfrequentie, chiptype, antennegedrag, gecodeerde data, reader-output, controllerconfiguratie, deurrechten, databasestatus en soms encryptiesleutels. Als één schakel niet klopt, wordt een goede kaart nutteloos bij de deur.

Mismatch in frequentie en chiptype

Het eerste punt om te begrijpen is dat RFID-kaarten voor toegangscontrole niet universeel zijn omdat ze er hetzelfde uitzien. Een witte PVC-kaart kan een 125 kHz LF-chip, een 13,56 MHz HF-chip, een MIFARE Classic-chip, een MIFARE DESFire-chip, een NFC-chip, een UHF-inlay of een dual-frequency combinatie bevatten. Twee kaarten kunnen identiek ogen, hetzelfde gedrukte logo dragen en toch totaal verschillende interne technologie hebben. Een reader voor 125 kHz proximity-kaarten leest normaal gesproken geen 13,56 MHz smartcard. Een reader die is ingericht voor één versleutelde DESFire-applicatie kan een andere DESFire-kaart met een verkeerde applicatiesleutel negeren. De plastic kaartdrager is niet de credential. De chip en de data vormen de credential.

Praktijkvoorbeeld: kantoortoren in Melbourne

Een vastgoedbeheerder in Melbourne bestelde vervangende RFID-kaarten voor toegangscontrole in een gemengde kantoortoren. De kaarten zagen er hetzelfde uit als de oude batch en hadden dezelfde personeelsnummers. Op de desktop-reader van de leverancier gaf elke kaart een stabiel nummer. Maar bij de hoofdingang van het gebouw reageerden de readers niet. Nadat iemand het oorspronkelijke systeem controleerde, bleek de oorzaak eenvoudig: het gebouw gebruikte 125 kHz proximity-credentials, terwijl de nieuwe kaarten 13,56 MHz-kaarten waren. De inkoper had gezocht op “RFID access card” en aangenomen dat alle RFID-kaarten uitwisselbaar waren. Er was niets mis met de nieuwe kaarten. Ze communiceerden alleen op de verkeerde radiofrequentie.

Een vergelijkbare fout ontstaat wanneer inkopers de frequentie wel kennen, maar de chipfamilie over het hoofd zien. Een 13,56 MHz-kaart is niet automatisch compatibel met elke 13,56 MHz-reader. MIFARE Classic, MIFARE Ultralight, MIFARE DESFire, NTAG, iCLASS-achtige credentials en andere HF-kaarten vallen binnen hetzelfde algemene frequentiebereik, maar gebruiken verschillende geheugenstructuren, beveiligingsmodellen en readerverwachtingen. Als de toegangsreader een specifiek kaarttype of een specifieke applicatie verwacht, kan hij een kaart weigeren die technisch uitleesbaar is, maar niet als geldige credential wordt geaccepteerd.

Praktijkvoorbeeld: hotelkeycards in Berlijn

Een hotelgroep in Berlijn veranderde het ontwerp van de keycards van glanzend wit naar matzwart en vroeg om dezelfde RFID-hotelsleutelkaarten, maar dan met een luxere uitstraling. De fabriek produceerde nette 13,56 MHz-kaarten en de bedrukking was uitstekend. Toch weigerden de hotelsloten het grootste deel van de batch. De oude kaarten gebruikten een chipprofiel dat geschikt was voor het slotsysteem, met sectordata die op een specifieke manier was geschreven. In de nieuwe inkooporder stonden alleen frequentie en kaartformaat, niet het vereiste chipmodel en de encodeermethode. De kaarten waren niet defect. Ze waren simpelweg niet voorbereid met de datastructuur die het hotelslotsysteem verwachtte.

Fouten in codering, formaat en facility code

Het coderingsformaat is een andere belangrijke reden waarom goede kaarten worden geweigerd. In veel toegangscontrolesystemen stuurt de reader niet het volledige chipgeheugen naar de controller. Hij stuurt een credentialnummer in een bepaald formaat. Dat formaat kan een facility code, site code, kaartnummer, parity bits, bitlengte of aangepaste data-indeling bevatten. Wiegand 26-bit, 34-bit, 37-bit, 40-bit en andere formaten kunnen verschillende outputs geven op basis van vergelijkbare kaartdata. Als de controller één formaat verwacht en de reader of kaart een ander formaat levert, ziet het systeem mogelijk een nummer dat niet in de database bestaat.

Praktijkvoorbeeld: magazijn in Toronto

Een logistiek magazijn in Toronto had duizenden personeelsbadges die waren gecodeerd in een 34-bit formaat. Toen er een nieuwe poort werd toegevoegd, gebruikte de installateur readers die waren ingesteld op een gangbare 26-bit output. De nieuwe poort weigerde perfect werkende personeelskaarten, terwijl dezelfde kaarten wel bij de hoofdingang van het kantoor functioneerden. Het troubleshootingteam vermoedde eerst een slechte kaartbatch. De echte oorzaak was het outputformaat van de reader. Zodra de readerconfiguratie werd aangepast aan de bestaande 34-bit credentialstructuur, werkten de geweigerde kaarten direct.

Een mismatch in facility code komt vooral vaak voor bij vervangingsorders. Een inkoper stuurt een zichtbaar kaartnummer en vraagt de leverancier dezelfde reeks te maken. De leverancier drukt de juiste nummers en codeert wat een correcte nummerreeks lijkt, maar de verborgen facility code is anders. Voor de gebruiker is kaartnummer 10237 gewoon kaartnummer 10237. Voor de controller is facility code 118 met kaartnummer 10237 niet dezelfde credential als facility code 214 met kaartnummer 10237. De deur is niet koppig. Het systeem volgt de database.

Praktijkvoorbeeld: schooldistrict in Texas

Een schooldistrict in Texas bestelde op maat bedrukte RFID-personeelspassen met de juiste namen, foto’s en gedrukte ID-nummers. De kaarten zagen er professioneel uit en waren door de leverancier uitleesbaar. Toch werden ze bij verschillende scholen geweigerd aan deuren van lesvleugels. Later ontdekte het district dat de oude kaarten een locatiespecifieke facility code gebruikten die jaren eerder door de oorspronkelijke integrator was toegewezen. De nieuwe leverancier had alleen de zichtbare personeelsnummers gecodeerd. Nadat de juiste facility code aan het encodeerbestand was toegevoegd, werden dezelfde kaartnummers geldige credentials in de toegangscontrolesoftware.

Verwarring over kaartnummers kan ook ontstaan door decimale notatie, hexadecimale notatie, bytevolgorde en UID-interpretatie. Het ene systeem toont een chip-UID in decimale vorm. Een ander systeem toont dezelfde UID hexadecimaal. Een reader kan de bytevolgorde omdraaien. Een database kan slechts een deel van de UID opslaan. Een leverancier kan een EPC coderen, terwijl het toegangsplatform een kaartserienummer verwacht. De inkoper denkt dat iedereen het over hetzelfde kaartnummer heeft, maar drie systemen kunnen drie verschillende versies tonen.

Praktijkvoorbeeld: fitnessketen in Dubai

Een fitnessketen in Dubai gebruikte NFC-lidmaatschapskaarten voor lockers en toegangspoorten. Het mobile-appteam sloeg de chip-UID hexadecimaal op, omdat een NFC-testtelefoon het nummer zo weergaf. Het toegangscontrolepaneel toonde dezelfde credential decimaal nadat de bytevolgorde was omgekeerd. Nieuwe kaarten leken ongeldig, omdat de nummers niet overeenkwamen met de ledenadministratie. De kaarten waren in orde. De data-interpretatie niet. De keten loste dit op door exact vast te leggen welke identifier werd gebruikt, hoe deze werd geconverteerd en hoe hij in de toegangscontrolesoftware moest verschijnen.

Encryptie en beveiligde credentials

Encryptie voegt een diepere laag toe aan kaartweigering. Moderne toegangssystemen gebruiken vaak beveiligde credentials waarbij de reader de kaart eerst moet authenticeren voordat data wordt uitgelezen. MIFARE DESFire-kaarten, versleutelde smartcards en sommige propriëtaire credentials kunnen applicatiesleutels, bestandsinstellingen, key diversification of secure messaging vereisen. Als de kaart de juiste chip heeft maar de verkeerde sleutel of geen applicatie bevat, kan de reader de fysieke aanwezigheid van de kaart zien, maar weigeren deze als geldige credential te behandelen. Voor de gebruiker lijkt de kaart dood. Voor de reader is de authenticatie mislukt.

Praktijkvoorbeeld: corporate campus in Amsterdam

Een corporate campus in Amsterdam stapte over van oudere proximity-kaarten naar versleutelde DESFire-toegangskaarten. Een afdeling bestelde extra kaarten bij een leverancier die echte DESFire-kaarten leverde, maar geen toegang had tot de applicatiesleutels van de campus. De kaarten konden als lege smartcards worden gelezen, maar de beveiligde readers weigerden ze bij elke deur. Het probleem was niet de echtheid van de chip. Het probleem was het ontbreken van personalisatie voor de toegangsapplicatie. Nadat de security-integrator de juiste applicatie en gediversifieerde sleutels had geladen, werden de kaarten geldig. Daarom moeten beveiligde toegangskaarten nooit alleen op chipnaam worden besteld.

Database, rechten en controllerproblemen

Sommige kaarten worden geweigerd omdat ze niet zijn ingeschreven, verkeerd zijn ingeschreven of door softwareregels worden geblokkeerd. Dat klinkt voor de hand liggend, maar het komt opvallend vaak voor. De kaart kan aan de deur correct worden gelezen, waarna de controller de database controleert en geen passende persoon vindt, een verkeerde toegangsgroep ziet, een verlopen geldigheidsdatum constateert, een gedeactiveerde status aantreft, een anti-passback-overtreding registreert, een blacklist voor verloren kaarten raadpleegt of een tijdschema toepast. In dat geval weigert niet de reader de kaart. Het toegangscontrolesysteem weigert de toegangsaanvraag.

Praktijkvoorbeeld: ziekenhuis in Manchester

Een ziekenhuis in Manchester gaf verpleegkundigen vervangende RFID-badges na een afdelingsverhuizing. De kaarten werkten bij de hoofdingang voor personeel, maar niet bij opslagruimtes voor medicatie. De kaartleverancier werd gevraagd onderzoek te doen, maar uit de toegangslogs bleek dat de kaarten correct werden gelezen. De oorzaak lag in de toegangsgroepen. De nieuwe afdelingsdeuren hadden een aparte rechtenregel, en de nieuwe badges waren nog niet aan die groep toegevoegd. De kaarten waren goed. De databaserechten waren onvolledig.

Controllergeheugen kan een tweede verwarrende situatie veroorzaken. In sommige systemen worden credentials vanaf de server naar lokale controllers gepusht. Als een controller de laatste update niet heeft ontvangen, kan een nieuw ingeschreven kaart bij de ene deur werken en bij een andere deur falen. Netwerkvertragingen, offline panelen, synchronisatiefouten of vol controllergeheugen kunnen goede kaarten slecht laten lijken. Een inkoper kan de kaart testen bij een lobbyreader die aan een bijgewerkte controller hangt en aannemen dat het hele gebouw klaar is, terwijl afgelegen deuren dezelfde credential nog weigeren.

Praktijkvoorbeeld: productievestiging in Slowakije

Een productievestiging in Slowakije voegde een nachtdienst toe en gaf op vrijdagmiddag nieuwe RFID-personeelskaarten uit. De hoofdturnstile accepteerde ze, maar verschillende deuren naar productiegebieden weigerden ze in het weekend. De securitymanager vermoedde een coderingsprobleem. Op maandag ontdekte de integrator dat twee controllers offline waren geweest tijdens de credentialdownload. Na synchronisatie werkten dezelfde kaarten zonder opnieuw coderen. Dit laat zien dat troubleshooting voor toegangscontrole ook de controllerstatus moet omvatten, niet alleen kaarttests.

Readerconfiguratie en fysieke factoren

Readerconfiguratie kan net zo belangrijk zijn als kaartcodering. Multi-technology readers ondersteunen vaak meerdere kaarttypen, maar niet alle modi zijn standaard ingeschakeld. Sommige readers kunnen worden geconfigureerd om UID, sectordata, beveiligde applicatiedata of een aangepast nummer uit te sturen. Andere readers kunnen zowel 125 kHz- als 13,56 MHz-credentials lezen, maar de installateur kan één technologie uitschakelen om ruis te beperken of de beveiliging te verhogen. Als de reader is ingesteld om een kaarttype te negeren, kan de kaart perfect zijn en toch onzichtbaar blijven bij de deur.

Praktijkvoorbeeld: coworking-operator in Singapore

Een coworking-operator in Singapore stapte over van eenvoudige proximity-kaarten naar dual-frequency toegangskaarten, zodat oudere deuren en nieuwe smart readers tijdens een gefaseerde upgrade konden worden ondersteund. De kaarten waren correct geproduceerd met zowel LF- als HF-chips. Toch weigerden de nieuwe liftreaders de HF-credential, omdat de installateur de readers tijdens het testen in legacy LF-only outputmodus had laten staan. Nadat de HF-modus en de juiste outputmapping waren ingeschakeld, werkten de kaarten zoals bedoeld. De dual-frequency kaart was niet het zwakke punt. De readerconfiguratie was dat wel.

Fysieke leesproblemen kunnen ook op credentialweigering lijken. Als de antenne in de kaart beschadigd is, als de kaart te ver van de reader wordt gehouden, als de kaart in een metalen portemonnee zit, als een telefoonhoesje stoort of als de reader dicht bij metaal is gemonteerd, ontvangt de reader mogelijk geen stabiel signaal. Het toegangscontrolesysteem weigert dan misschien helemaal geen credential, omdat er nooit een credential binnenkomt. Daarom moet een mislukte tap eerst op RF-niveau worden gecontroleerd voordat software of codering de schuld krijgt.

Praktijkvoorbeeld: luxe appartementencomplex in Vancouver

Een luxe appartementencomplex in Vancouver installeerde nieuwe glazen deuren met metalen kozijnen en compacte toegangsreaders die rechtstreeks op een roestvrijstalen plaat waren gemonteerd. Bewoners klaagden dat hun RFID-keycards alleen werkten wanneer ze onder een vreemde hoek werden aangeboden. De kaarten werkten normaal op een desktop-reader, waardoor de leverancier in eerste instantie de schuld kreeg. Het echte probleem was de installatie van de reader. Het metalen montageoppervlak verkleinde het effectieve leesveld. Een afstandsplaat en aangepaste readerpositie losten het probleem op. De kaarten waren vanaf het begin goed.

Ook de kaartconstructie kan invloed hebben. Dikke clamshell RFID-kaarten, dunne ISO-kaarten, keyfobs, polsbandjes, wooden RFID cards, epoxy tags en bedrukbare PVC-kaarten kunnen dezelfde chip bevatten, maar zich bij de reader anders gedragen door antenneformaat, materiaal, oriëntatie en afstand. Een reader die is afgestemd op standaardkaarten presteert niet automatisch optimaal met elke vormfactor. Als een inkoper overstapt van kaarten naar keyfobs of van PVC-kaarten naar houten kaarten, moet vooraf met de echte reader worden getest voordat massaproductie start.

Daarnaast bestaat het probleem van dubbele credentials. Een kaart kan worden geweigerd of gemarkeerd als het nummer al in het systeem voorkomt, aan een andere gebruiker is gekoppeld of eerder als verloren is geregistreerd. Dit kan gebeuren wanneer leveranciers testnummers hergebruiken, wanneer inkopers onvolledige nummerreeksen aanleveren of wanneer meerdere locaties overlappende facility codes gebruiken. Een goede bestelling van toegangskaarten vraagt om gecontroleerde nummering, geen dubbele EPC’s of kaartnummers, en een databestand dat elk gedrukt nummer koppelt aan de gecodeerde credential.

Inkopers lopen ook vast wanneer ze compatibele kaarten bestellen zonder precies te begrijpen wat compatibiliteit betekent. Compatibel kan dezelfde chipfamilie betekenen. Het kan dezelfde frequentie betekenen. Het kan hetzelfde gedrukte formaat betekenen. Het kan betekenen dat de kaart door dezelfde encoder leesbaar is. Het betekent niet automatisch dat de kaart elke deur in het systeem opent. Echte compatibiliteit omvat chip, geheugenstructuur, coderingsformaat, beveiligingssleutels, reader-output, facility code, datalengte en inschrijfproces. Wanneer RFID-kaarten voor toegangscontrole cruciaal zijn voor het functioneren van een gebouw, moet compatibiliteit met samples worden bewezen.

De slimste methode voor troubleshooting is om de keten stap voor stap te volgen. Controleer de kaartfrequentie. Controleer het chiptype. Controleer of de reader de kaart überhaupt detecteert. Controleer welk nummer de reader uitstuurt. Vergelijk die output met het databaserecord. Controleer facility code en bitformaat. Controleer of de kaart is ingeschreven, actief is en aan de juiste toegangsgroep is gekoppeld. Controleer controllersynchronisatie. Controleer readerconfiguratie. Controleer montagecondities en leesafstand. Pas daarna zou iemand mogen concluderen dat de kaart defect is.

Voor inkopers die vervangende RFID-kaarten bestellen, moet de inkoopspecificatie gedetailleerder zijn dan “hetzelfde als vorige keer”. Stuur waar mogelijk fysieke oude kaarten naar de leverancier. Lever chiptype, frequentie, geheugeneisen, coderingsformaat, facility code, kaartnummerreeks, printvereisten, beveiligingssleutels via de bevoegde integrator indien nodig, en een procedure voor sampletests aan. Als het systeem versleutelde credentials gebruikt, betrek de toegangscontrole-integrator dan vroeg in het proces. Een kaartfabriek kan de kaartdrager produceren en veel dataformaten coderen, maar kan geen beveiligde applicatiesleutel raden die alleen de systeemeigenaar of integrator beheert.

Voor installateurs en facility managers zijn toegangslogs onmisbaar. Een geweigerde kaart die in het eventlog verschijnt als onbekend nummer is een ander probleem dan een kaart die helemaal niet in het log verschijnt. Een onbekend nummer wijst op dataformaat, inschrijving of rechten. Geen event wijst op readerdetectie, frequentie, chipcompatibiliteit, veldsterkte, bekabeling, voeding of readerconfiguratie. Wie het log zorgvuldig leest, kan dagen aan verkeerde troubleshooting voorkomen.

Een goede leverancier van RFID-kaarten voor toegangscontrole stelt vragen die in het begin misschien lastig lijken. Welk readermodel wordt gebruikt? Welk kaarttype werkt nu? Zijn 125 kHz-, 13,56 MHz- of dual-frequency kaarten nodig? Gebruikt het systeem MIFARE Classic, DESFire of een andere beveiligde credential? Welk outputformaat verwacht de controller? Zijn facility codes vereist? Moet het gedrukte nummer overeenkomen met het gecodeerde nummer? Is een sampletest op de echte deurreader nodig? Dit zijn geen vertragingen. Dit zijn de redenen waarom de uiteindelijke kaarten zullen werken.

De waarheid is dat de meeste geweigerde RFID-toegangskaarten geen slechte kaarten zijn. Het zijn mismatched credentials, verkeerd geconfigureerde readers, onvolledige databaserecords, niet-gesynchroniseerde controllers of verkeerd begrepen nummerformaten. Zodra de volledige keten zichtbaar is, verdwijnt het mysterie. Een perfect geproduceerde RFID-kaart kan worden geweigerd omdat ze de verkeerde frequentie, de verkeerde chip, de verkeerde applicatie, de verkeerde sleutel, de verkeerde facility code, het verkeerde bitformaat, de verkeerde bytevolgorde of de verkeerde toegangsgroep heeft, of simpelweg nog niet in de controller is geladen.

Dus voordat u de kaart de schuld geeft, vertraag het proces en vraag wat de deur werkelijk ziet. Detecteert de reader de kaart? Welk nummer wordt verstuurd? Kent de controller dat nummer? Mag de gebruiker op dat moment door die deur? Is de reader geconfigureerd voor dit kaarttype? Is de credentialdata op dezelfde manier opgebouwd als bij de oude werkende kaarten? Als die antwoorden kloppen, hoort een goede RFID-kaart voor toegangscontrole te werken. Als één antwoord niet klopt, blijft zelfs een perfect geproduceerde kaart buiten de deur staan, samen met iedereen die wacht tot het systeem haar herkent.