Does your access control system have healthy credentials?

Andrew Sieradzki, group director, Security, at Buro Happold on how to introduce a new access control system

Undoubtedly many of the readers of this article have an association with electronic access control systems (EACS), whether through their day to day in gaining unfettered access into their offices, or through the specification, delivery or administration of access control systems into buildings.

The initial widescale adoption and deployment of electronic access control systems commenced in the late 1970s; from a practitioner’s perspective these systems have generally had a long life cycle – typically exceeding the traditional electronic system 10-year lifespan model. However, even now there are a plethora of these systems that are running perfectly satisfactorily in their second decade (and sometimes longer) of operation. The administrators of these platforms may not be aware that they have potentially significant exposure in terms of system efficacy due to the gradual depreciating and potentially insecure nature of these systems and the data contained on them.

While many systems have gradually been transitioned to modern platforms, there is often a concern in terms of any proposed upgrade, with a veiled nervousness from clients as to the amount of disruption such changes have on their workplace and their workforce. The bigger the organisation, the more complex and intricated the issue becomes – especially in a post Covid-19 world of flexible working. This may be a legacy view that is cast from past card transition experiences; however, there is undoubtably some merit in being cautious about embarking on a task that involves changing the keys to the kingdom of all users; the prospect of mass lockout does not inspire the balance sheet or executive board particularly favourably. Typically, these systems involve everyone concerned, where the individual users get to take a piece of the security platform (i.e. their passes) away from the workplace and are then trusted to look after them. It is hard to picture how this would work if this practice was adopted for every other type of security solution deployed within the workplace (just imagine having the opportunity to take a piece of the CCTV solution home with you). There is therefore nervousness in new technology adoption, and the need for an understanding of the full use case of the access control ecosystem.

Adopting a new a system
One favourable transition option often considered when replacing a large system is to adopt the existing legacy token/user credential/card estate and build the replacement solution around this with a view of creating a pathway to later adopt a new card downstream of the deployment. This does equate to a more seamless transition, and many successful replacement solution deployments have utilised this method, but this approach is not without its risks.

During adoption of this approach, some careful consideration needs to be made as to the legacy credentials encoding and enciphering (if any), where once discovered, typically require importing into the replacement solution. This is not an insignificant task: even if the credentials’ known security vulnerabilities may have been exploited to initially extract its enciphering keys and encoding pattern, did this action breach any originators latent IP? Was there any consideration by the end users in gaining permission from the original credential provider to adopt these formats? Furthermore, any consequential failure at this juncture often leads to adoption of a big bang approach to credential replacement, where you may have a true period of running the old solution in tandem with the new, until you can replace the legacy platform. This is not an insignificant and disruptive task without pre-planning and the hope of a forgiving workforce.

Another often overlooked aspect of adopting replacement credentials is their initial configuration and architecture, which may end in circulation for potentially numbers of decades. Indeed, what consideration was made if their enciphering keys were ever compromised, and what type of standards were adopted from the outset? Was the fallback position considered where you can recover from a ‘loss key’ breach and ‘roll the card family keys’ without replacement of the entire card family? Where such breaches are considered serious enough, the alternative is of course to replace the whole card estate; reputationally, this is not a good position to be in. Then there’s the knotty problem of how these keys are stored on the cards – are these static and common throughout your entire card family, and do you care if these get compromised? The alternative is to consider diverse keysets on each card. This, while a complex process to initiate, does ensure that each card in your estate is completely unique from a key material perspective, and that when an individual card is compromised, this generally only equates to that single card and not your entire suite of cards.

Once you have decided on the card technology, its architecture and enciphering credentials, do you then want to encode (which is quite distinct from enrolling cards) these cards on site? Or will you farm this capability out to the supply chain, and hope that your most sensitive card aspects (keys which are required for the encoding process) don’t become compromised?

In remedy of this vulnerability, a far more manageable approach is to encode your cards on your premises, with your own securely held enciphering key family and production platform. Generally, well designed solutions incorporate these keys on to a third party validated hardware secure module (HSM) and therefore do not expose these assets to the wider supply chain or internet during your card encoding processes. Furthermore, it is entirely possible for the end user to transport these HSMs to trusted card encoding providers (if large scale is a requirement), deployed for the production run and then returned to their originator once the encoding run is completed.

There are a lot more of these under-the-hood aspects of credential selection to consider at the design stage, especially if you consider and add mobile platforms to the mix. However, there is also a great emphasis on the type of access control system itself, its features and benefits, and of course cost. Selection consideration should always consider the functionality of these systems, but merit should also be given to the security aspects. For instance, how is the (user) data both in transit and at rest accounted for – is it enciphered? Are the communications between your access reader endpoints and door controllers secured? i.e. Open Supervised Device Protocol (OSDP): who holds the respective enciphering keys? What resilience do you have for system signalling faults – does the system keep running?

Larger solutions can typically span many buildings or may even span a global workforce. The security and respective data processing considerations need to be considered, especially where cross jurisdictions are in force.

In conclusion, while not promising to be a comprehensive and detailed end-to-end discussion on selection of electronic access control credentials, my top tips are:

Do ensure that you know what your exposure is to the supply chain in terms of your credential, equipment and data enciphering keys. Ensure you have full and recoverable ownership of these and can store and use them securely. Also consider the eventual destruction/removal of sensitive data with any end-of-life ACS components.

Do ensure you have a well-designed token infrastructure based around an independently validated credential platform that caters for secure encoding practices and uses diverse keysets for each token.

Have a plan B, C and indeed D – design in a key rollover capability within your token family to ensure that if there is a key compromise you can recover without an immediate and full card replacement programme.

Whenever conducting an ACS transition, plan well in advance for triaging and cleansing legacy user data and provide good clear communications as to how the transition process will take place.

Test, test and re-test: build in time and resource to conduct testing of the solution in phases before full deployment, and work with all stakeholders (including fire safety, accessibility and security representatives) in mapping out the whole life cycle of EACS use, including pass production, attesting user data, access rights, failover considerations and end of life considerations.

Use advice from reputable trade industry bodies and base your designs on current standards including GDPR. Select equipment from independently attested bodies e.g. CPNI Access Control Assured and CPNI CAPSS assured.

Select your system installer and maintainer carefully – make sure they belong to a relevant trade body e.g. NSI, SSIAB etc and that they are familiar with and trained on the equipment they plan to install for you.

Make sure you get sufficient training to operate and administer the solution and sufficient consumables to maintain credential production, and never underestimate the time taken for any transitional bulk pass production run.

Have a means in place to shred/securely dispose/recycle spent components and consumables (including credentials).

Don’t share your most critical and sensitive material i.e. enciphering keys with an unknown and attested supply chain.
Don’t simply throw away spent card printing consumables (noting that some production techniques genuinely produce truly excellent negatives of all your staff passes as a ‘by-product’).

Don’t share user data sets without some form of data sharing agreement that binds the parties contractually to process your data appropriately.

End of life components may contain some of your most critical assets; adopt a responsible security minded approach to destruction/recycling of these.

In conclusion, the selection, design, installation maintenance and administration of access control systems is a complex web of processes and workflows that involves everyone within an organisation.


View the latest
digital issue