# Decreasing Physical Access Bottlenecks through Context-Driven Authentication

Klutso Lebea, Wai Sze Leung

► To cite this version:

Klutso Lebea, Wai Sze Leung. Decreasing Physical Access Bottlenecks through Context-Driven Authentication. 17th International Symposium on Human Aspects of Information Security and Assurance (HAISA), Jul 2023, Kent, United Kingdom. pp.285-295, 10.1007/978-3-031-38530-8_23 hal-05462097

HAL Id: hal-05462097

https://inria.hal.science/hal-05462097v1

Submitted on 16 Jan 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
<figure><img src="image_2.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
<figure><img src="image_3.png" /></figure>

# Decreasing Physical Access Bottlenecks through Context-Driven Authentication

Khutso Lebea(✉) and Wai Sze Leung

University of Johannesburg, Johannesburg, South Africa
{klebea,wsleung}@uj.ac.za

**Abstract.** Despite advancements made to improve the effectiveness and efficiency of access control mechanisms deployed in cyber-physical environments, their controlling logic-driven systems may remain heavily dependent on user interaction during the authentication process. In instances where elevated security requirements are warranted, the authentication methods may be multi-factored in nature, leading to bottlenecks that become more pronounced during peak traffic hours. Logical access control has considered location and time for authentication and re-authentication for some time now and context-driven authentication is fast becoming a standard feature of enterprise-class publicly available products and is used in financial technology (fintech), and eCommerce solutions. This paper focuses on the prototype implementation of context-driven authentication in a cyber-physical access control environment, deployed in a large organization that makes use of information typically collected in the course of the organization's business operations to uphold security requirements while maintaining efficient access control.

**Keywords:** Context-Driven · Authentication · Cyber-Physical Security · Access Control

## 1 Introduction

When it comes to security systems, the engineers behind their design tend to prioritize security and accuracy, typically using such metrics to determine the system's performance [1]. Such metrics work well in systems that do not require interaction from its users (such as background services and system-to-system communication), whereas end-users have repeatedly demonstrated a preference and acceptance for user-facing systems that promote convenience and speed [1, 2]. The success of any user-facing system is often determined by user acceptance, with users typically refusing to accept systems they feel are difficult to use, intrusive, or unsafe [3, 4]. Anecdotal evidence suggests that when forced to use systems that are viewed as cumbersome, users may end up finding workarounds, often at the cost of lowering the system's security and accuracy-driven features [3]. Specifically, the incorrect use of the features can produce incorrect results, with some cases introducing security issues [4, 5]. The same is true for access control in cyber-physical environments.
This paper continues the work done by the authors in a paper titled "A Model for Context-Driven Authentication in Physical Access Control Environments" [6].

This paper examines how a context-driven approach can be successfully applied to manage access control at an organization that makes use of multi-factor authentication mechanisms and struggles with the challenges of long queues more efficiently. Section 2 begins by exploring the challenges of designing efficient cyber-physical access control environments, leading to an overview of the Context-Driven Physical Access Control Model in Sect. 3. The implementation of this model is then documented in Sect. 4. Section 5 discusses the evaluation of the model, identifying potential improvements before concluding in Sect. 6.

## 2 Cyber-Physical Access Control Environments

A physical environment is defined as an area in the real world, this paper focuses on enclosed areas that are access controlled, the access to which is typically controlled and enforced through physical barriers such as boom gates, turnstiles, and locks, along with a security officer who will identify the credentials of those requesting access and will manually operate the physical barriers if the access request is successful [7, 8].

Thanks to advancements in numerous authentication mechanisms, organizations have a variety of options when it comes to designing how their cyber-physical access control systems authenticate users into their enclosed areas, with choices in the type of authentication mechanisms deployed depending on the organization's simplicity, security, and budgetary requirements.

Time to authenticate will always increase when additional authentication mechanisms are introduced, when users are ill-trained on how to operate a particular authentication mechanism, unnecessary time is added to the overall authentication process [2, 9], much to the detriment of an organization that requires users to move through the access control point quickly. While increased training may assist in addressing this concern, it is not necessarily a suitable solution for organizations dealing with a frequently-changing user group (for example, the students at a university with new incoming users and outgoing users around every six to twelve months). The training of users can be expensive and would not eliminate the time added by each contact-driven authentication mechanism. To exacerbate matters, organizations with elevated security requirements may require multiple authentication mechanisms to increase the accountability and certainty of their access control efforts. With each authentication mechanism requiring user interaction, the overall time to complete the authentication process would only be extended [2]. Consequently, such bottlenecks may threaten an organization's productivity or negatively impact its operations (e.g. a large group of students needs to gain access to campus in order to write their ex-amination starting in the next five minutes), leading to security officers opting to relax or bypass the authentication requirements completely. Ultimately, such decisions which compromise the security and accounting features of the system are far from ideal [10].

In contrast, a system that is context-aware can be seen as a suitable solution to finding an optimal balance between simplicity and security while keeping costs in mind. While manually accessing a physical access control point, if a user is known by the security
officer on duty and that user is not in possession of their authentication token(s), the security officer may make an informed decision to relax authentication requirements for that user. By that same token, a context-aware cyber-physical access control solution would be able to take the information it has of its surroundings to make dynamic and optimal judgment calls when it comes to deciding whether a user wishing to gain access must be subject to part of or the full authentication process [11]. In this manner, context awareness can be used to bridge the gap between the usability and security of a cyber-physical environment.

# 3 Context-Driven Physical Access Control Model

The Context-Driven Physical Access Control Model (CPACM) is designed with the goal of dynamically determining the degree of authentication each user must undergo at an access control point in order to reduce the overall time taken at access control points. This is achieved by considering a user's contextual knowledge (such as historical and situational information) to determine whether it may, for the current access request, forego additional authentication mechanisms that are typically required.

Figure 1 provides an overview of the CPACM which is designed in a modular fashion to promote cost-effectiveness for organizations seeking to adopt a context-aware approach to managing their access control systems. As seen in the illustration, examples of context information that will be processed include temporal and location data.

## 3.1 Main Control Unit

The Main Control Unit (MCU) is the primary component responsible for making the dynamic authentication decisions for each access request - it determines this by considering the context information it receives from the context modules (Temporal Profile Module and GPS Module in Fig. 1) to generate a certainty score. Depending on whether the certainty score meets the threshold set by the organization's security administrators, the MCU will determine whether the user who has successfully authenticated themselves on the first authentication mechanism will be required to verify themselves further with a second factor mechanism. All access decisions, successful or not, are stored in the Authentication Database (AD).

The next two subsections will provide an overview of two context data modules which are responsible for maintaining a database of users' contextual patterns, thus allowing the MCU to make its context-aware decisions.

## 3.2 Temporal Profile Module

The Temporal Profile Module (TPM) is responsible for building profiles of the various users who request access by maintaining the temporal patterns of the users. Specifically, the TPM collects data relating to the time and day that a user makes access requests from the access control system, creating a rolling average for each user daily. The TPM uses this information to determine whether a user requesting access at a given point is consistent with the other times when they request access.
<figure><img src="image_4.png" /><figcaption>Fig. 1. Architecture of the Context-Driven Physical Access Control Model.</figcaption></figure>

The TPM also takes into consideration the consistency in which users make such requests, keeping in mind when users have a history of making access requests in an inconsistent manner (these can refer to users who might not work fixed hours at an organization).

## 3.3 GPS Module

For organizations using cyber-physical access control systems at multiple access points, the location at which a user requests access can also play an important role in assisting the MCU in its decision-making. Similarly, to how the TPM maintains a profile of each user based on their access time, the GPS module records the location at which a user is making the access request. In essence, the GPS module records a list of frequently used access points that the user typically visits. Such a list assists the MCU in determining whether a user is behaving “normally” or warrants additional authentication to confirm a user’s identity.

## 3.4 Authentication Flow

Figure 2 illustrates the authentication flow as described in Subsects. 3.1, 3.2, and 3.3. It is important to note that Fig. 2 does not depict the entire model, the diagram only shows the parts that are important for an authentication decision. The other components that make up the overall access control system (authentication devices and access point infrastructure such as card readers and turnstiles, respectively) are not represented.

When a new user is added to the system, they will not have any profile information stored in the AD for a successful authentication request, the system will deny the request and request a secondary authenticator from the user and a profile will be created for that user. Ideally, this will be a minority of the system users.

When a user has a profile, a match in the AD will be found, however, should the user have insufficient profile information in the AD, the certainty score will not be high
<figure><img src="image_5.png" /><figcaption>Fig. 2. Authentication Flow.</figcaption></figure>

enough for a successful authentication request. The AD will then request the context modules (namely the TPM and the GPS Module) to use the access request information provided to determine a certainty score.

Should the combined certainty score calculated by the individual modules not be high enough for a successful authentication request, the system will ask that the second-factor authentication mechanism be used.

As more access requests are made and a user pattern begins to emerge, the access requests will be successful, and the need for a contact-driven secondary authenticator will be minimised. Thus, reducing the authentication time and user-facing complexity of the system.

# 4 Model Implementation

## 4.1 The Physical Access Data Set

To test that the model would work in a real world environment a data set was needed. There did not seem to be any publicly available data sets on entry and exit logs for cyber-physical environments. A University was approached and asked for their campus entry and exit logs. Ethical clearance along with anonymizing the data was a requirement before obtaining the records.

The data set obtained had more than 34000 entries, and all the user's personal details were removed. The first step was to process the data into a relational database format from the Excel format that data was received in. Then the information was separated by user, day, and access point groupings.

Within the 34,000 + records in the data set were 305 unique users. The data set had records for a period of 11 months (February to November 2019). Of the 305 unique users, there were five different roles: cleaning staff (48); academic staff (48); protection service staff (48); support staff (54); and students (107).

The data set presented several challenges to the research. Each of these is described in the subsections that follow.
## 4.2 Potentially Missing Data

The data set only had complete information on successful campus entry and exit, this outlook is not realistic because other outcomes happen in real life that the data set did not represent.

- **Access denied:** a user is not permitted access to that part of the campus.

- **Successful entry but no exit record:** a user exists the campus in a vehicle as a passenger.

- **Successful exit with no entry record:** a user enters the campus in a vehicle as a passenger.

Typically, passengers are not asked to authenticate so their information is not captured at the outermost layer of the access control system.

It is therefore unclear whether certain information was not captured, or that such records were omitted from the data set to provide a data set with “complete” records. Regardless, the concern does influence the aspects of the CPACM implementation.

## 4.3 Prototype Implementation

The anonymized digital research artifacts can be found at Implementation of the CPACM (Fig. 3).

<figure><img src="image_6.png" /><figcaption>Fig. 3. CPACM Graphical User Interface (GUI).</figcaption></figure>

The prototype was designed to test a single user’s access request. The GUI was designed to simulate a card reader interface as a proof of concept. Incorporating an actual card reader would take up a lot of time, and the point of this prototype is not to see if the card reader works or not, that is assumed. The test is to see if a correct access decision will be taken. The data required by the GUI is:

- **User ID:** This is a student number or a staff number because the data set has been sanitised of all personal data, the ID is just an integer value used to identify different users in the database.
- Access Point Name.

- **Access request time:** The time a user is requesting access. (obtained by the Hour, Minute, and Second).

- Day of the week.

- Entry or exit.

The “Access Request” Button simulates an access request equivalent to a user presenting a smart card to a smart card reader, all the above information will be captured and sent to the MCU for an access decision. If the access request is rejected, the user is required to use their secondary authenticator. All the access requests are recorded regardless of the outcome.

# 5 Evaluation of Model

Evaluation of the prototype demanded that the data set be split into two parts. One part would be used as a training set for the prototype, and the other part would be used as a testing set. The training set needed to be significantly larger than the testing set, so it consisted of 10 of the 11 months of the data set, and the testing set was the last month of November 2019.

## 5.1 Results

The testing set consisted of 2236 entries even though it was data for a single month and most of the 305 users had an entry. Because the entries in the data set had information for both entry and exit times, the batch process was run only for the campus entry requests. This was done to simplify the testing. After training the model with the training set and creating all the user profiles, the testing set was introduced to the prototype as a batch process to be run against the profiles created using the testing set. Of the 2236 entries, only 1479 access requests were successful and 757 were unsuccessful.

<table><caption>**Table 1. Test Results**</caption><thead><tr><td>Iteration</td><td>Requests</td><td>Successful</td><td>Unsuccessful (GPS)</td><td>Unsuccessful (Time)</td><td>Access %</td></tr></thead><tbody><tr><td>1</td><td>2236</td><td>1479</td><td>172</td><td>585</td><td>66.14</td></tr><tr><td>2</td><td>2236</td><td>1568</td><td>89</td><td>579</td><td>70.13</td></tr><tr><td>3</td><td>2236</td><td>1651</td><td>26</td><td>559</td><td>73.84</td></tr><tr><td>4</td><td>2236</td><td>1677</td><td>0</td><td>548</td><td>75.00</td></tr><tr><td>5</td><td>2236</td><td>1677</td><td>0</td><td>548</td><td>75.00</td></tr></tbody></table>

The testing set was once again batch-processed through the prototype (simulating repetition and user patterns) to see if the TPM and the GPS Module absorbed the 1479 successful access requests and the supplemented 757 requests that required the user to present their secondary authenticator. If so, it would mean that the modules are evolving
with the new inputs. As illustrated in Table 1, additional iterations of the same data indicate an increase in the number of successful access requests without the need for a secondary authenticator. However, the improvements started to plateau after the fourth iteration, which is why testing was halted.

The plateau is because the time difference between the average daily access time and the access request time was too far apart and the certainty level was too high for the MCU to ever grant access.

Different user groups affected the results differently, users from the cleaning service group were assigned their duties weekly, and from the data set it was evident that these assignments were sometimes random and inconsistent at both time and access point where a cleaning service member would request access. This led to the consideration of more granular ways of treating each group of users, for instance, the access request response for a cleaning service group member should consider a duty assignment roster and a student group member's response should consider that student's timetable.

The need for granularity or at least the introduction of more contextual inputs for the access decision can be seen in Table 2 where academic staff has the lowest standard deviation for both campus entry and exit. The 2:32:12 is a result of calculating an average based on each individual's entry standard deviation in the group.

<table><caption>**Table 2.** Standard Deviation of all User Types</caption><thead><tr><td>User Type</td><td>Users</td><td>Standard Deviation</td></tr></thead><tbody><tr><td>Academic Staff</td><td>48</td><td>02:32:12</td></tr><tr><td>Support Staff</td><td>54</td><td>07:40:12</td></tr><tr><td>Protection Service</td><td>48</td><td>09:06:36</td></tr><tr><td>Cleaning Service</td><td>48</td><td>05:48:30</td></tr><tr><td>Student</td><td>107</td><td>06:34:07</td></tr></tbody></table>

The average deviation is likely attributed to the fact that academics mostly have a fixed schedule for an entire semester. In contrast, protection services and cleaning staff users exhibited the highest standard deviation values, possibly as a result of their working schedule and the change of work shifts. These groups typically do not have much control over their movements on campuses as there is usually a weekly or monthly schedule that dictates when they should be on campus.

## 5.2 Considerations

Considering the issues identified with the data set and the problems faced during the testing of the prototype, the results obtained are expected and prove that contextual information has the potential to be used as a background second authentication mechanism and reduce the time it takes to authenticate. It is important to note that the number of successful access requests can be higher with some changes. Unfortunately, the cleaning
staff and student schedules could not be obtained to prove this theoretical observation in a practical sense.

To avoid the prospect of an unauthorised user who has access to an authorised user's smart card and knowledge of the authorised user's patterns on campus gaining access to parts of the campus otherwise restricted to them, the model could request users to randomly authenticate using the fingerprint scanner even on a successful access request. A more reliable, but costly solution to this problem can be the addition of more contactless means of collecting situational information, such as a camera module that would be used to identify the user using biometrics such as gait recognition or facial recognition. The model is designed to handle additional authentication factors, ideally, factors that do not require user interaction.

The random request would ideally be enforced during off-peak hours to not further increase the authentication time during peak hours. The idea of this random second-factor authentication request is similar to the random screenings that airport security conducts and that of smartphones requesting the user to use their secondary authentication method if they have not used it for some time [12].

# 6 Conclusion

This paper aimed to explore the implementation of a context-driven approach called Contextual Physical Access Control Model (CPACM) and its potential to address issues with contact-based multi-factor authentication in cyber-physical access control environments. The objective was to determine if incorporating situational information could enhance convenience and speed without compromising security and accuracy.

The results of the CPACM implementation showed a 33.86% failure rate after the first authentication attempt, which reduced to 25.00% after the fourth attempt. This highlights the model's learning and adaptability, as users give more data points to the system for a more accurate user profile. Furthermore, with 75% of users not requiring their secondary authenticator at access points, the likelihood of bottlenecks at those points decreased, while maintaining the organization's security standards.

One notable advantage of context-driven authentication is that users are typically unaware of the background authentication processes taking place. Since the context-driven factor does not require user interaction, it is less prone to user acceptance issues. This finding suggests that context-driven access control models should be considered as a viable solution for bridging the gap between the security and accuracy of an access control system and the convenience and speed it offers.

It's important to note that these conclusions are specific to the CPACM implementation mentioned in the paper. When considering the adoption of context-driven authentication in a different environment, factors such as infrastructure, user demographics, and organizational requirements should be carefully evaluated to ensure the suitability and effectiveness of the chosen approach.
# Appendix A: The Access Control Data Set

This appendix describes the format of the original data set used in the prototype. After ethical clearance at the university was obtained, the researcher was provided with a data set in the form of a Microsoft Excel file containing more than 34 000 access log entries.

The table attributes in the file are described as follows:

- **Type:** distinguishes the user types, in this data set there are five types of users, namely Academic Staff, Support Staff, Protection Service, Cleaning Services, and Students.

- **Employee/Student:** This field identifies the user, although there are five distinct user types, they are separated by either staff or student and student numbers are different or use a different format for employee or staff numbers.

- **Date:** The date when access was granted.

- **Campus:** The university has more than one campus, the access logs keep track of which campus the user accessed. The campus field stores the name of the campus a

- **Control Name In:** Each campus has multiple access points; each access point has a name. Control Name In stores the access point is used for entry.

- **Terminal In:** Each access point has multiple physical barriers, for example, the main gate could have four turnstiles for walk-in access and two boom gates for vehicular entry. Terminal In stores the name of the actual barrier used.

- **Campus Out:** Stores the name of the campus the user exited, a direct opposite of the Campus field. (should have the same campus name as the corresponding Campus field).

- **Control Name Out:** opposite of the Control Name In the field, Control Name out stores the name of the access point used to exit campus.

- **Out Terminal:** stores the name of the barrier used to exit, Out terminal is the opposite of the Terminal (In) field.

- **IN Time:** Records the time a user entered the campus.

- **Out Time:** Records the time a user left campus.

# References

1. Scott, C., Wynne, D., Boonthum-Denecke, C.: Examining the privacy of login credentials using web-based single sign-on -are we giving up security and privacy for convenience? In: Cybersecurity Symposium (CYBERSEC), pp. 74–79. IEEE (2016). https://doi.org/10.1109/CYBERSEC.2016.019

2. Ramatsakane, K.I., Leung, W.S.: Pick location security: seamless integrated multifactor authentication. In: 2017 IST-Africa Week Conference (IST-Africa), pp. 1–10. IEEE (2017). https://doi.org/10.23919/ISTAFRICA.2017.8102391

3. Matthews, B.R.: Physical security: controlled access and layered defence. In: Encyclopedia of Information Assurance, Auerbach Publications, pp. 2275–2283 (2010)

4. Albrecht, A.: Understanding the issues behind user acceptance. Biometric Technol Today 9, 7–8 (2001). https://doi.org/10.1016/S0969-4765(01)00124-2

5. Bandyopadhyay, K., Fraccastoro, K.A.: The effect of culture on user acceptance of information technology. Commun. Assoc. Inf. Syst. 19, 522–543 (2007). https://doi.org/10.17705/IC AIS.01923
6. Lebea, K., Leung, W.S.: A model for context-driven authentication in physical access control environments. In: Kim, K.J., Kim, H.-Y. (eds.) Information Science and Applications. LNEE, vol. 621, pp. 319–328. Springer, Singapore (2020). https://doi.org/10.1007/978-981-15-1465-4_33

7. Hussein, M., Han, J., Colman, A.: An approach to model-based development of context-aware adaptive systems. In: 2011 IEEE 35th Annual Computer Software and Applications Conference, pp. 205–214. IEEE (2011). https://doi.org/10.1109/COMPSAC.2011.34

8. Collins, L.: Access controls in cyber security and IT infrastructure protection. In: Syngresse, pp. 269–280. Waltham (2014)

9. Nídlová, V., Hart, J.: Reliability of biometric identification using fingerprints under adverse conditions. Agron. Res. **13**, 786–791 (2015)

10. Reynolds, J., Smith, T., Reese, K., Dickinson, L., Ruoti, S., Seamons, K.: A tale of two studies: the best and worst of YubiKey usability. In: 2018 IEEE Symposium on Security and Privacy (SP), IEEE (2018)

11. WhatIs.com: Context Awareness. https://tinyurl.com/yxotny2a. Accessed 5 Dec 2018

12. Horan R.: TSA PreCheck Now Includes Random Screening of Electronic Devices. https://tinyurl.com/5emj898r