skip to content

IT Help and Support

University Information Services

University physical security: University Card best practice

Document ref: UCC/008/22
Author: Natalie West
Version 1, 26 April 2022

1. Purpose

This document provides best-practice guidance for managing security with regards to the University's electronic card and card systems. The purpose of this is to equip security decision-makers with the guidance they need to make informed decisions.

The term 'Unique Identifier (UID)' is used to refer to any number, present or future, that is uniquely assigned to a card, for the purpose of identifying a that card. The detailed specification for the current card technology is available on request.

2. Physical Security

The University Card – in conjunction with the card reader and door controller – forms one part of the University’s security environment. The card can be used to grant the cardholder access from a non-secure area to a secure area e.g. public access area into a University building. 

Consideration should be given to the sensitivity of the assets located in the area and whether higher security enclaves should be established inside the secure area, e.g., the cage used to protect high value assets in the University Library, the additional access control systems used for Physical Containment Lab (PC3), and server room restricted access.

3. Authentication Management

Cardholder authentication is performed by comparing the card’s unique identifier (UID) read electronically from the physical card to the card UID retrieved from the Card API (Application Programming Interface).

The local system should obtain the card details – including the card UID – from the Card API using an automated data feed, fetching data at regular intervals to ensure the local access system maintains the current list of ISSUED cards while automatically removing RETURNED, REVOKED and EXPIRED cards from the local access system.

The reader should read the card UID directly from the card memory and not rely on other data that may or may not be present on the card.

The read key used to access the card UID should only be known to those who need to configure the physical access hardware and should be treated with the same consideration as other sensitive passwords i.e., accessed on a need-to-know basis, no sharing in plain text etc. Contact the Card Office if you require a copy of the read key as part of setting up a new access system.

4. Visual identity verification

A comparison between the physical appearance of the cardholder and the photo printed on the front of the University Card may not be sufficient to verify the cardholder's identity. Government issued identity documents (e.g. driver’s licence, passport, national id card etc) can be used as part of a proof of identity check.

In most instances, the card is sufficient to demonstrate the cardholder physical appearance matches the official record held by the University. The name as it appears on the card reflects the chosen name of the cardholder and may not reflect their legal name.

A more secure approach to verifying the identity of a cardholder is to compare the cardholder's physical appearance to the details returned by the Card API and/or the card frontend web application. The card UID can be used to return the details of a specific card. The cardholders CRSid can be used to return the cards associated with that cardholder. For offline access, card details can be downloaded in advance. Security decision makers will need to balance the risk/implication of cardholders presenting a fake university card against the inconvenience of implementing stricter verification approaches when deciding what is appropriate for each situation.

5. Monitoring

The local access system should log events such as failed and successful logins, the time the event occurred and the access point that registered the event.

All security incidents relating to the University Card or Access Only card should be documented when discovered, and the University or College security, and the University Card Office via the UIS Service Desk should be promptly notified. Examples of such incidents are card cloning, card emulation or replay attacks.

6. Local Policy Development

Establish internal policy and procedures to ensure appropriate management of University Cards and Access Only cards. The following is an example of best practice; however, it may need to be adapted to suit each institution’s circumstances: 

  • Cards are reported as lost/stolen as soon as is known.
  • Cards reported as lost/stolen are immediately revoked.
  • As part of the offboarding process, cards are collected from departing cardholders and disabled immediately unless the cardholder is known to have other affiliations which entitle them to continue to hold a card.
  • When Access Only cards are issued, the card UID, issue date, name of the cardholder and any other relevant information is recorded.
  • Access Only cards are only enabled at the point of issue to a named individual.
  • Access Only cards are automatically disabled after a set period, e.g. 3 days
  • Access Only cards are only issued to cardholders requiring temporary or short-term access, if long term access is required the Card Representative should normally request a UCAM Card

If you would like guidance on creating your local access-only card policy, please contact the UIS Service Desk for advice.