Published 10 March 2020

Abstract

Physical access control systems (PACS) are becoming more integrated with Logical Access Control Systems (LACS) via Identity and Access Management (IAM) deployments. This direction is further evidence of the trend towards expanding the breadth of IAM services under consistent governance and security models. There have been continued efforts by many vendors to converge these two environments in response to increasing compliance mandates, requirements to better manage alternative user populations such as on-premises visitors and contractors, and an acute emphasis on timely and secure access. In this sense, standard capabilities such as a common authenticator and automated integration with user provisioning are relatively mature. The goal of this integration is to have one service that choreographs access to both facilities and IT resources.

The purpose of this report is to dive into the concepts and conceptual architectures of converged Physical Access Control Systems (PACS) and Logical Access Control Systems (LACS), referred to as PACS-LACS convergence. This insight addresses the typical enterprise objective to migrate their current set of multiple building/facilities access systems to a single PACS and LACS solution that is more secure, easier to maintain and able to be deployed across the entire organization. These solutions, which in many cases are becoming quite mature in the PACS market must also comprise a complete solution that includes video surveillance, high-availability, fault tolerance, and end-to-end administration and monitoring.

Author:

Doug Simmons Principal Consulting Analyst [email protected]

Executive Summary

Physical access control systems (PACS) are becoming more integrated with Logical Access Control Systems (LACS) via identity and access management deployments. There have been continued efforts by many vendors to converge these two environments in response to increasing compliance mandates, requirements to better manage alternative user populations such as on-premises visitors and contractors, and an acute emphasis on timely and secure access.

In our recent research reports titled “Zero Passwords in a Zero Trust World” and “Multi-Factor Authentication (MFA): Enterprise Strategy and Market Assessment” TechVision Research discusses the need and opportunities to implement better forms of authentication – beyond the password, for accessing IT assets. In this report, we dive into what for many has been the ‘holy grail’ of authentication capabilities – the convergence of physical access control to buildings, facilities, rooms and so forth with the logical access to IT resources such as the enterprise network(s), applications and systems.

What we mean by converged is that a single medium, such as a form of token (something you have) can be combined with something you know (e.g., a PIN), something you are (e.g., facial recognition) and some form of contextual awareness (e.g., where are you located right now?) to grant access to both facilities and IT resources in accordance with an individual’s existing affiliation with the enterprise.

Readers who are embracing the emerging Zero Trust security framework should therefore be heartened. Convergence of PACS and LACS instills harmony between the physical identities of the carbon-based world with the IT-centric, logical representation of everyone and everything in the emerging Digital Enterprise. Convergence done properly organically reduces the attack surface. Trust can be established or refuted with fewer lookups, decisions and margin for error.

This report will show you that there are presently a number of options for integrating or converging PACS with LACS. This has been an objective for many enterprises – large and small, over the past decade and more. While the U.S. federal government was able to enforce the deployment of PIV (personal identity verification) cards in the 2005-2010 timeframe for PACS-LACS (and the Department of Defense’s Common Access Card (CAC) even before that), the rest of the business world has been watching and waiting for secure-but-economical migration options to emerge. That time appears to have come.  The pervasiveness of smartphones, IP networks, cloud services and IAM maturity has brought to bear the opportunity enterprises can embrace.

This report illustrates and explains the concepts and conceptual architectures of converged Physical Access Control Systems (PACS) and Logical Access Control Systems (LACS), referred to as PACS-LACS convergence. This insight addresses the typical enterprise objective to migrate their current set of multiple building/facilities access systems to a single PACS and LACS solution that is more secure, easier to maintain and able to be deployed across the entire organization. These solutions, which in many cases are somewhat nascent in the PACS market must also comprise a complete solution that includes video surveillance, high-availability, fault tolerance, and end-to-end administration and monitoring.

From an administration standpoint, the primary integration required for realizing such convergence exists within the Identity and Access Management (IAM) and Identity Governance and Administration (IGA) pillars of the enterprise IT security program. Here is where the journey begins, as the fundamentals of converged PACS and LACS will logically center on these capabilities.

From an IAM point of view, the primary integration point is with the user and account provisioning subsystem. Provisioning (as well as de-provisioning) focuses on automating as much as possible the onboarding of new employees, contractors and possibly other constituencies (i.e., students, faculty, managed service suppliers and so forth). This automation is typically in the form of real-time connectors or agents that interface with authoritative source systems of identities, such as HR, Contractor Management and second-level authoritative sources such as Microsoft Active Directory, enterprise LDAP, Azure AD or other cloud-based identity repositories. We describe this level of automated integration in detail in our document titled “eBook: IAM Reference Architecture”.

It is important to understand that PACS-LACS convergence does not focus only on the authenticator, which incorporates the common identity management processes that make the converged card possible.  In reality, convergence is very conducive to contextual authorization – making decisions about application access based upon the user’s location (either on-premise or off-premise) and security event correlation – the visibility into user activity from when they enter the facility to their subsequent activity in logical applications. Digging deeper, the runtime authorization capabilities of IAM environments are capable of taking contextual awareness into account when deciding (during runtime) whether to let someone or something ‘in’ via logical access control. These same runtime capabilities can be extended to physical access as well, so that ‘time of day’, ‘last location and time of access’ and information of this nature can be used to increase the granularity in runtime physical access control.

IGA is supported by the enhanced provisioning and de-provisioning capabilities as we combine logical and physical access systems. For example, as described in the TechVision report “Designing and Implementing Effective Enterprise Identity Governance and Administration Program” we state that the goal behind IGA is simple: Ensuring appropriate access, when and where it is needed. IGA combines entitlement discovery, decision-making processes, access review and certification with identity lifecycle and role management. IGA operates in the intersection of business process management and access automation allowing people and systems communicate with each other, fulfilling day-to-day operational needs. It focuses on the process and operational components of identity and access management. IGA is focused on addressing issues related to the mapping of business objectives to policies as well as creating a platform for the execution and administration of these policies. IGA is a bridge between the business decision makers and those that administer the technology in support of managing all aspects of governing access. To converge PACS and LACS means to extend IGA to monitor, audit and enforce physical access management as well a logical (IT) access.

In this report, we are providing you with the preliminary tools to conduct an assessment of your own enterprise physical and logical security infrastructure and strategy.  The desired outcome of this report is to help you develop a more thorough understanding of its infrastructure and process strengths, gaps, areas of concern, and existing “good practices” necessary to develop a realistic PACS-LACS convergence strategy.  Therefore, in addition to sharing advancements in convergence technologies, we will help you examine how user identity lifecycles are managed; how information entitlements are assigned, monitored and revoked; and how user identities are audited – across both PACS and LACS environments.

Introduction and Background

Distilling a long market history, there are two main types of access control systems. The first is the traditional method where control panels act as hubs for door readers, door locks, cameras and the system’s interface, usually a PC. These door readers and control panels connect with proprietary power and serial (e.g., RS-232) communication wiring.

Newer PACS systems are built on Internet Protocol (IP) networks, including cloud-based systems, in which the facilities access readers are connected the IP network through ethernet or wireless connectivity. Eliminating the need for control panels, IP-based PACS are therefore often less complicated and easier to install via standard IP network hubs.

IP systems have gained popularity as cloud storage becomes more pervasive and they are much simpler to set up – usually with simply an ethernet connections to the enterprise network instead of serial connections to multiple control panels. There is no limit to how many door readers can connect to an IP system, while in a traditional system, control panels can only be connected to a handful of doors. From a scalability and integration standpoint, IP-based PACS are much more economical.

Convergence projects like we are discussing here often require the upgrading of PACS to be able to reduce the number of card authentication techniques or update the PACS to support a specific smart card type (e.g., for the HSPD-12 PIV card in widespread use across the U.S. federal government).  Understand that PACS rely upon readers and controllers that in many cases support thousands of doors in the environment and often use proprietary wiring schemes, such as the Weigand interface (developed in the 1970s).  While the upgrade of these PACS components can often be a multi-year project for many large organizations, they can today leverage multi-protocol readers, controllers, and cards to ease some of this transition and buy additional time to facilitate the upgrade. However, it bears mentioning that the PACS wiring scheme may need to be converted to an IP-based network and this can increase the cost – sometimes substantially.

It is important to understand that the stability and security of the enterprise IP network is a critical factor when determining whether an enterprise should replace hardwired serial PACS with more modern IP-based componentry. Just as hackers can wreak havoc on enterprise IT systems protected by LACS, PACS can be just as hackable once they are connected to an IP network. Note that details about overall network security is covered in several dedicated TechVision Research reports, so in discussing PACS-LACS convergence simply understand that IP network security principles apply.

Physical and Logical Access Convergence

For well over the past decade, the use of a common authenticator has been possible through a ‘converged access card’.  Typically, these access cards have been ID badges combined with traditional PKI-based smart cards. In this way, converged smart cards enable people to access resources protected by physical access control systems (PACS), as well as traditional applications that can leverage X.509 PKI authentication.  In addition, the ISO 7816 (credit card sized) badge provides an area to print visual identification and even human readable authentication information.  In this way, the user can be visually authenticated by the physical security staff.  Combined with the embedded chip, the converged smart card also provides stronger authentication for logical applications. Therefore, the converged badge has two interfaces: the contactless interface that enables authentication to the physical perimeter, and the chip-based contact interface that enables multi-factor authentication to the IT devices, network and applications.

Some of the major changes since this early convergence includes:

• The emergence of the smartphone as a viable token for identification and authentication for both physical and logical security.
• The continued pervasiveness of IP networks as the global communications infrastructure.
• The embracement of cloud-first strategies that compel enterprises to migrate away from on-premise technologies to cloud-centric approaches.

With this as a backdrop, we can now start to drill into the current state of PACS-LACS convergence and share with you the significant advancements that may compel you to begin a long-awaited PACS-LACS convergence program.

Typical Architecture

We’ll start with the basic/traditional architecture for PACS and then explore some new architectural approaches for both PACS and the ultimate convergence of the physical and logical access control systems. Components of a typical physical access control system include:

• An access control panel (also known as a controller)
• An access-controlled entry, such as a door, parking gate or other physical barrier
• A reader installed near the entry. (In cases where the exit is also controlled, a second reader is used on the opposite side of the entry.)
• Locking hardware, such as electric door strikes and electromagnetic locks
• A magnetic door switch for monitoring door position
• Request-to-exit (REX) devices for allowing egress.

A high-level look at such and architecture is illustrated below.

Figure 1: Traditional PACS Architecture

Access control decisions are made by comparing the person’s credentials to an access control list. This look-up can be done by a host or server, by an access control panel, or by a reader. While ‘legacy’ PACS typically conduct the user lookup on a central server, more current systems push the look up to the edge of the system, or the reader instead. The predominant topology for the past decade or so has been ‘hub and spoke’ with a control panel as the hub, and the readers as the spokes. But things are changing as we’ll describe during much of the remainder of the report.

Game Changer: The Smartphone

Today, a growing number of PACS vendors support the use of a smartphone to perform most functions a Physical Access Control System (PACS) can provide, including:

• Badge verification
• Entry/Exit tracking
• Remote opening of doors
• Visitor management

What this provides is support for the use of an application on an NFC or Bluetooth Low Energy (BLE) enabled smartphone to open a door. For most physical access, employees open doors using their badge (RFID, magstripe or other technology), PIN, and/or biometric credential. This advancement in ‘token’ technology recognizes the pervasiveness of smartphones today, and the PACS industry identified smartphones as a legitimate new medium to store credentials. Without question, this sea change is aided by Apple iOS and Google Android both embracing Bluetooth NFC.

The use of the cell phone to open a door or gate provides some significant advantages, such as:

1. Bluetooth range can be several feet instead of inches.
2. People often have their cell phones in their hands, which is convenient at doors.
3. It does not require another device.

Of additional value of course is that the smartphone can also be used for logical access within the enterprise’s multi-factor authentication strategy. In plain sight, this is the convergence we’ve been looking for. While smart cards embedded in physical access badges have been around for many years – and certainly in widespread use across government agencies, such technology was difficult, cumbersome, complex and expensive for many organizations to deploy effectively, especially globally.

However, as you might expect there are still some challenges for mobile phones within PACS technology. For example, one’s cellphone does not work with a dead battery. Furthermore, the PACS market is rather fragmented, with each vendor maintaining their own competing, proprietary infrastructures that require replacement of all the readers at points of access. Mobile credentials also have a significant learning curve and management overhead. Lastly, these credentials are subject to different attack vectors than security personnel see with physical credentials.

All that being said, smartphones are still the ‘wave of the future’ for PACS (a future that started a few years ago) and in TechVision’s opinion they provide the link that brings converged PACS/LACS into a practical reality.

Cloud Based PACS

In addition to locally hosted access control systems – where the server is on-premise in the data center, cloud-based solutions are emerging rapidly. In cloud-based PACS, access permissions are not stored on a local server, but in the cloud. This means that the administrator can manage the permissions from multiple locations by using a (TLS-enabled, secure) browser. This appeals to security managers charged with overseeing multi-location facilities for one, and of even more importance, it radically changes how quickly PACS servers can be deployed across the globe.

As an example, Lenel’s OnGuard platform can be optionally configured and tuned to allow PACS server deployment across Amazon Web Services (AWS) cloud infrastructure. For some, this may be of significant value, especially if the enterprise has been waiting for years to upgrade their PACS infrastructure and have dreaded the amount of time, effort and cost it would take to accomplish.

In summary, modern, converged PACS-LACS environments are shaping up like the high-level architecture illustrated below.

Figure 2: Modern Converged PACS-LACS

Standards

For interfacing with readers, there are many defacto standard card technologies including magnetic stripe, bar code, Wiegand (Wiegand wire is attracted to magnets), 125 kHz proximity, 26-bit card-swipe, contact smart cards, and contactless smart cards. Also available are key fobs, which are more compact than ID cards, and attach to a key ring. Biometric technologies include fingerprint, facial recognition, iris recognition, retinal scan, voice, and hand geometry. The built-in biometric technologies found on most smartphones can also be used as credentials in conjunction with access software running on mobile devices. And, as we have said, newer technologies such NFC and Bluetooth can also communicate user credentials to readers for system or building access.

OSDP

The Open Supervised Device Protocol (OSDP) has emerged as a legitimate access control communications standard in the PACS space. It was developed by the Security Industry Association (SIA) to improve interoperability among access control and security products. OSDP v2.1.7 is currently in-process to become a standard recognized by the American National Standards Institute (ANSI), and OSDP is regularly reviewed an updated to retain its industry-relevant positioning.

This standard is in wide use by many leading manufacturers like Cypress, HID Global, Mercury and others and the Security Industry Association encourages broad adoption of OSDP and recommends specifying this standard for any access control installations with security requirements. It is particularly valuable for government applications because OSDP meets federal access control requirements like PKI for FICAM (Federal Identity Credentialing and Access Management). Compared to common low-security legacy protocols, the emerging OSDP standard offers:

• Better security than the most common (defacto) access control communications protocols.
• OSDP Secure Channel supports high-end AES-128 encryption (required in federal government applications).
• OSDP monitoring of wiring to mitigate attacks.
• Supports advance smartcard technology applications, including PKI/FICAM and biometrics.
• Supports bi-directional communications among devices.
• OSDP supports a more advanced user interface (than earlier approaches), including welcome messages and text prompts.
• OSDP’s use of 2 wires vs. 12+ allows for multi-drop installation, supervised connections to indicate reader malfunctions, and scalability to connect more field devices.
• Audio-visual user feedback mechanisms provide a rich, user-centric access control environment.
• Predefined encryption.
• Multi-vendor communication if all parties are using OSDP.
• The standard applies to peripheral devices (PDs) such as card readers and other devices at secured access doors/gates and their control panels (CPs).
• The OSDP specification is currently recommended when TCP/IP, USB, or other common protocols do not lend themselves to the application.
• The OSDP specification is extensible to IP environments and the OSDP WG is working on deploying OSDP over IP soon.

OATH

Authentication standards are emerging and should be considered as a starting point for an enterprise converged PACS-LACS program. For instance, the Initiative for Open Authentication (OATH) addresses authentication integration challenges with standard, open technology that is freely available to application developers. OATH is a collaborative effort and seeks to provide a reference architecture for universal strong authentication across users, devices and networks. Through an open standard, OATH describes itself as offering more hardware choices, lower cost of ownership, and allow customers to replace existing disparate and proprietary authentication systems whose complexity often leads to higher costs. OATH’s framework components are designed to be interoperable by enabling integration with existing identity and access management platforms and infrastructure (e.g. LDAP directories, web access management and single sign-on servers).

The OATH standard, at a basic level, describes implementation of a core set of authentication credentials. These credentials are:

• One Time Password (OTP) – based authentication
• Public key infrastructure (PKI) – based authentication (using X509.v3 certificate)
• Subscriber identity module (SIM) – based authentication (using GSM/GPRS SIM)

The OATH standard has been ratified in a series of IETF RFCs. Because OATH-based solutions can be compatible, migration between products is intended to become simpler and can leverage a much larger range of devices for OTP generation, such as YubiKey, and even sharing of hardware tokens between vendors. An important architecture goal for universal authentication is to enforce the separation between validation and identity stores. OATH recommends that all identities (user or device identities, as well as device-to-user bindings) be maintained outside the validation server. This separation is important from an integration and cost-control standpoint because it promotes a distributed architecture that favors the reuse of an enterprise’s existing infrastructure (e.g., corporate directories). In such architectures, the validation server is a minimal front end. OATH assumes that LDAP (including Active Directory and Azure Active Directory) is used to enable the validation server and the directory to exchange information. The OATH standard is currently being contributed to by a large number of vendors, including Gemalto, HID, Symantec, VASCO, Yubico and many others (please see https://openauthentication.org/members/), and is supported by a number of MFA vendors (discussed in further detail later in this document).

FIDO

Another important standard in the identification and authentication arena has been developed and promulgated by the FIDO (Fast Identity Online) Alliance, an industry consortium launched in February 2013 to address the lack of interoperability among strong authentication devices (PayPal and Lenovo were among the founders).

FIDO’s aim is to support a full range of authentication technologies, including biometrics, Trusted Platform Modules (TPM), USB security tokens, smart cards, and near field communication (NFC). FIDO specifications provide two categories of user experiences, depending on whether the user interacts with the Universal Second Factor protocol or the Universal Authentication Framework protocol. Both of these FIDO standards define a common interface at the client for the local authentication method that the user deploys. The client can be pre–installed on the operating system or web browser.

FIDO members total more than 260, including a Board made up of Aetna, Amazon, American Express, Bank of America, Gemalto, Google, Intel, Lenovo, MasterCard, Microsoft, NTT DoCoMo, PayPal, Qualcomm, RSA, Samsung Electronics, USAA, Visa, VMware, Yubico and many others.

Looking to the Future

We have seen over the past 2-3 years a tipping point where the use of mobile credentials with access control systems becoming commonplace. While we anticipated this shift for years, the widespread adoption of mobile phones for more varied uses is now becoming the norm. An example of such usage is Apple’s launching of contactless student IDs to over 100,000 students across the United States.

Because the use of mobile and other contactless credentials has proven successful, end users – whether employees, contractors or consumers are becoming more comfortable with the idea (of smartphone-based credentials) and more willing to use these credentials at work and home.

Access control is more sophisticated than ever as we see existing technologies like artificial intelligence acquiring increased capabilities, and technologies like biometrics, becoming more mainstream and accessible to organizations of all shapes, sizes and geographies.

AI is already supporting access control systems by detecting unusual or suspicious activity and sending alerts, recognizing faces, and gathering and analyzing pertinent data. TechVision Research expects advances in AI to continue to identify vulnerabilities, actively monitor facilities and perimeters, diagnose problems, and protect data. As we see growth in the convergence between physical and logical access controls, AI may also be used to alert human employees to security issues in real time, allowing faster responses.

Advances in the integration between PACS and IAM subsystems, such as automated user and device provisioning, workflow approvals and identity governance and administration (IGA) will continue. As PACS vendors continue to move their capabilities to the cloud, leverage mobile phones/devices and so forth, IAM vendors are adding service connectors between the provisioning and access logic from authoritative identity sources such as Active Directory, Azure AD, LDAP and so forth.

For example, Openpath (https://www.openpath.com/solutions/enterprise) is a physical access control vendor that provides administrators with cloud-based access to monitor and manage their environments, and end users with low friction access through e mobile credentials (as well as supporting traditional smart-card-based credentials). The four-year-old CA-based company has connectivity with AD/Azure AD, Okta, Google G-Suite, O-365 and Okta. Openpath can synchronize end users from Okta into Openpath while optionally auto-assigning them access credentials and permissions – and can also authenticate into the Openpath Control Center using SAML single sign-on from Okta. This is an example of how PACS can be integrated with the enterprise IAM infrastructure.

On the device reader side, ultra-wideband (UWB), is a new wireless, short-range communication protocol that allows devices to “talk” to each other. UWB is expected to be utilized in access control systems by allowing hands-free access to entry and exit points.

What we are seeing is a shift in access control from being strictly a security function to having a more comprehensive, user experience-based focus. These new offerings support not only the workplace, but any environment requiring access security. The key to more ubiquitous offerings lies in the convergence of the logical and physical access approaches and the integration into mainstream IAM services.

Typical PACS-LACS Convergence Requirements

There are several important customer capability requirements associated with the integration of their PACS systems with their enterprise IAM environments.  These requirements are identified below.

1. Dramatically Reduce the Time Lag ‘Badge’ Credentialing Process – Perhaps the most fundamental requirement for the identity management infrastructure in support of PACS is the dramatic reduction of the time it takes to provision a new employee, contractor, vendor or even visitor to create facilities access badges.
2. Converge on a Single Provisioning Interface – Enterprises need a single provisioning and de-provisioning dashboard for managing internal and external users, combining the capabilities of PACS and LACS and giving each administrative team (i.e., IT access administration, facilities security) the view of the subject relevant to their function.
3. Automate Provisioning from HR – An event trigger from HR should be used to create provisioning and de-provisioning workflows for internal employees. The automated provisioning should allow PACS administrators to review and approve (or deny) account creation/management/disablement/deletion activities, rather than requiring PACS administrators to start the provisioning process manually via a different set of processes and workflows, as is often done today. To accomplish this, more timely information capture processes within HR are required, which will also require an in-depth analysis and possible re-engineering of certain HR on-boarding and off-boarding policies, in order to more expediently manage information within the PACS environment.
4. Automate Provisioning from Contractor Management Systems – Similar to the HR integration requirement above, enterprises should be able to automate the account provisioning and de-provisioning process from event triggers in contractor management systems.
5. Converge Identity Data Repositories – Eliminate redundant identity data management data bases for the same users in both the LACS and PACS environments. The objective should be to leverage fewer – if not one, authoritative source repository for identities, such as AD/AAD for employees and contractors, as well as cloud-based Identity as a Service (IDaaS) identity repositories.
6. Support Logical Access Control Via MFA – Enterprises require the ability to support logical access control to its internal and externally facing systems using MFA. One of the most basic requirements for logical access is to support MFA authentication to the enterprise network and applications and be able to leverage that same MFA token (e.g., smartphone) for physical access.
7. Automate Identity Audit Reporting – Enterprises need the capability to determine who has access to specific systems and facilities across the enterprise – no matter the geographic span. This reporting capability should be supported on an “ad hoc” basis, as well as part of an annual recertification program. The process should be automated such that people who have fixed terms of employment, such as contractors, are automatically required to be recertified upon reaching the date of initial contract completion.
8. Determine Sponsorship for External Parties – Organizations need to determine who is responsible for issuing access credentials to contractors that are often working for several customers at once. Every non-employee person that enters a facility or has access an IT asset must have a sponsor accountable for their actions.
9. Establish PACS Software Standardization and Interconnectivity – To achieve convergence, PACS environments will need to be running the same software and be interconnected via the corporate IP network so that any identity and access privilege(s) can be assigned at any location. This is significant because PACS standardization will also require that many existing facilities badge readers be replaced in order to support the new token, such as the app-enabled smartphone.
10. Demand Comprehensive Reliability – Enterprises will accept no single point of failure for PACS (or LACS, for that matter). The new system must support PACS-specific backup servers to be accessible by all converged enterprise sites.
11. Streamline On-Boarding Processes – This is potentially the biggest gap in the current environments for many enterprises are the processes involving HR and the Security Administration office. Convergence means these processes must be carefully analyzed, and potentially streamlined in order to facilitate the creation of PACS-LACS credential in a reasonable timeframe so that it can be activated and used by a new employee or contractor within no more than 2-3 days of starting work (or less!).
12. Security Event Management – It is a common misconception that convergence focuses only on the authenticator – the converged identity token and the common IAM processes that make the converged card possible. In reality real convergence is also about security event correlation – the macro view of enterprise user activity from when they enter the facility to their subsequent activity in IT networks, systems and applications. For example, security information and event management (SIEM) products can collect and analyze information from PACS systems by accessing the PACS log file directly or via another log aggregator (e.g., Splunk et. al., to which most modern PACS systems can forward events). Correlation of PACS and logical system events can benefit both ongoing analysis and forensic investigations.
13. Contextual Authorization – PACS/LACS convergence is also about contextual authorization – making decisions about application access based upon the user’s location (either on-premise or off-premise). The benefit is better authorization policies for logical applications by including the user’s physical status (typically on-premise or off-premise). Some examples of organizational policies that incorporate physical location are:
    1. The user cannot access a Windows workstation in the local domain unless the user has badged into the local PACS.
    2. The use of the VPN should not be allowed if the user is on-premise, within the corporate firewall.
    3. Administrators may not access HR or payroll information unless they are on-premise, and so forth.
14. Emergency Access – Operationally, emergency access procedures are the cause of most of the high visibility pain and suffering. For example, the physical access token requires robust emergency access procedures – perhaps in concert but often different from LACS emergency procedures. Enterprises must provide workable alternatives for physical and logical authentication if the users forget their smartphone at home, it gets lost, stolen, etc.
15. Current PACS Card Reader Wiring – Many enterprises’ current PACS deployments utilize legacy card technologies, in which readers rely on the Weigand wire protocol to transmit data from door readers to the often on-premise PACS controller. The Weigand format and protocol – while they are the default specifications deployed in PACS today – are considered “old school” or legacy and are security risks.  Weigand was originally designed for a primitive (relative to the ISO 7816 smart card specification) contact card and does not support writing data to the card.  Weigand also requires specialized wiring – typically five wires from the door reader to the controller (two data wires, one power wire, one ground wire, and one for the LED on the reader). The immediate future puts the door controller on the network via TCP/IP over Ethernet in place of Weigand, while longer term, the trend may be toward Wi-Fi, which would support securing a door that is in a separate building from the host, as well as enabling the addition of a door in the building with minimal wire installation.

This is by no means a comprehensive set of detailed requirements for a PACS-LACS convergence program. However, this list is certainly intended to help you see the ‘big picture’ related to what it will take to undertake such an important program. The option to ‘do nothing’ always remains. But, the legacy PACS environments are going to be due for a major overhaul at some point as technologies continue to shift away from proprietary cabling to IP networks, the smartphone becomes the pervasive ‘token’ for LACS access, legacy vendors morph or go way and so forth. For many enterprises, that point is now.

A PACS-LACS Reference Architecture

As we have been discussing, an enterprise’s IAM infrastructure plays a key role in PACS-LACS convergence. The IAM infrastructure provides the principal means for the enterprise to manage the user identity lifecycle (e.g., onboarding, credentialing, access provisioning and removal/termination) from a logically centralized administrative interface. Most organizations rely on the IAM infrastructure to enable common identity administration across physical and logical resources.  Typically, the system used to interface with and make changes to the PACS is Active Directory and Azure Active Directory, enabling the PACS system integrate user attribute changes and group memberships, which correlate to access rights within the facilities secured by the PACS.

In principle, the organization should seek to implement a flexible, extensible, risk-aware enterprise authentication strategy that will accommodate current and future business needs and technologies. Typical future-state vision includes PACS-LACS authentication services that—

• Encompass risk-balanced user authentication to both facilities (PACS) and systems, networks, applications and services (LACS) for the target users.
• Support a strong user experience.
• Address the full range of assurance levels identified by the organization along with associated requirements.
• Support identification and authentication from a suitably wide range of devices.
• Enable the organization’s business processes and workflows.
• Ensure compliance and mitigate both physical and IT risks.
• Are easy to use, sustainable and cost-effective.

With these principles as a backdrop, let’s look into the TechVision IAM Reference Architecture with our PACS-LACS glasses on. The TechVision Research Reference Architecture for IAM is this starting point; a master template, shown in Figure 3, below, identifies the IAM capabilities (rather than technologies) that can be improved or enabled, allowing business stakeholders and technical architects to achieve a common language for IAM functions, which can then be refined over time. ­­­ This high-level template starts the journey:

Figure 3: IAM/PACS-LACS Master Template

The capabilities illustrated above are described at the highest level as:

Interact – how end-users and application developers interact with the IAM platform. In the case of PACS-LACS, this will involve a variety of diverse people and technology interactions.

Access – the rules that define the roles, rights, and obligations of any actor wishing to access enterprise facilities, IT assets or connected external IT assets.

Change – the capability to define and manage the relationships between the user/ application developer and the enterprise physical and logical assets.

Manage – the capabilities required to manage and upgrade the IAM solution itself.

Measure – the capabilities required to audit and improve IAM activities.

Store – the capabilities required to share identity information and relationships between the components of the IAM solution.

The Reference Architecture’s second level is depicted in Figure 4, below.

Figure 4 – Second Level: IAM Portfolio Capabilities Supporting an PACS-LACS Convergence Program

As discussions progress into deeper levels of discovery, this master template organizes discussions beginning with the high-level interfaces associated with both end-user and application developer IAM service consumption. From either of these perspectives, organizations can navigate deeper into the runtime functionality requirements for:

• Access (e.g., identification, authentication, authorization, federation, privileged access, etc.). The authentication interfaces are where PACS-LACS subsystems interact.
• Identity lifecycle management (e.g., joiner/mover/leaver, change orchestration, and governance). To be clear, PACS must be configured for end users and devices registered through identity lifecycle management interfaces.
• IAM infrastructure administration, including user facilities access control configuration and user administration.
• IAM data management and reporting. IAM solutions provide various types of reports recounting user interaction, suspicious activity, performance and reliability statistics and so forth. These should be extended to the physical, facilities realm.

Once the required capabilities are identified, the next layer of the TechVision Research Reference Architecture for IAM allows us to explore each of the specific technology or process elements comprising each capability in the form of a combined portfolio architecture, as illustrated in Figure 5, below.

Figure 5 – Third Level: Elements of the Combined Portfolio Architecture

Time of Access Operations rely on Time of Change Operations, such as identity lifecycle management (identity registration, provisioning, workflow) and identity orchestration (identity correlation, synchronization, transformation) to provide contextual information about users and their current state, permissions, and entitlements. For example, an authorization system may implement the policy that a user must authenticate with multi-factor authentication (MFA) to be granted access to specific facilities, networks, applications or services.

Adaptive or contextual authorization within the framework of PACS-LACS convergence strengthens authorization policies for logical applications by including the user’s physical status, such as whether he or she is on-premise or off-premise.  Some examples of organizational policies that incorporate physical location are:

• The user cannot access a Windows workstation in the local domain unless the user has badged into the local PACS
• The use of the VPN should be allowed if the user in on-premise

• HR or payroll information may not be accessed by administrators unless they are on-premise, and so forth.

An access policy enforcement infrastructure such as Policy Enforcement Points (PEPs) provides authentication of subjects – in our example, this would be the result of a token (e.g., mobile phone) with both PACS and LACS interfaces. In the following section, we’ll drill down further and provide a sample runtime authentication pattern to support both PACS and LACS.

TechVision PACS-LACS Integration Pattern

Users of any IT systems, whether employees, contractors, system administrators, customers, 3^rd parties or technology suppliers must authenticate themselves before being granted access. We need to remember that PACS now needs to be part of an overall authentication program and provide the right support and context for authorization decisions.

Authentication is the principle form of identification. Once authentication has been achieved, authorization is the next step as decisions need to be made regarding the granting access to a specific IT or other assets. The following factors (and many others) can then be used to support authorization decisions:

• Group membership in Active Directory, Azure AD or other sanctioned enterprise LDAP directory
• Attribute values stored within the Identity Data Service (attribute-based access control, or ABAC)
• Role values stored within the Identity Data Service (role-based access control, or RBAC)
• Combinations of the above

But the hard part is putting this all together and making the right authentication decisions; keeping out threats while properly engaging customer, prospective customer and employees with the right access at the right time. The complexity and impact of these decisions have led to the concept of adaptive authentication as we’ll further describe below.

The pattern covered in the following figure illustrates a consistent, uniformly applied, auditable and secure user runtime authentication and authorization future supporting converged PACS and LACS.  Details of initial identification and authentication may vary, but the point is that there is a policy-based decision that determines the required level of assurance given the current level of determined risk.  This is referred to as ‘adaptive authentication’, in that the additional authentication factors that can be enabled via PACS and LACS convergence are employed to attain that determined level of identity assurance.

Figure 6:  Converged PACS-LACS Service Pattern

The architecture pattern is further described via “steps” in the following process:

Steps 1 and 2: The architecture above introduces the core infrastructure components of the PACS enrollment system administrative interface (Step 1) coupled with IAM provisioning (Step 2) to push enrollment data to downstream systems, such as the PACS enrollment processes, which may perform personnel background checks and the enrollment and issuance of PACS-specific identifiers, respectively. The delegated administration process for capturing the new employee or  contractor can be supported by either a) a product specialized for this purpose, such as Lenel OnGuard or, b) the IAM provisioning subsystem customized to capture the necessary identity information for PACS as well as LACS provisioning. Note that this step can be performed by the Security Division (as it is often done today), the Human Resources’ hiring manager or the hiring manager of the contractor.

Steps 3 and 4: Upon successful completion of the preliminary background check by whomever is responsible for this (e.g., HR just as an example), the user information is sent to the PACS Enrollment Server and IAM. The PACS Enrollment Server then stages the adjudication process, assigns the user record with the PACS unique ID and alerts the Enterprise Security Division that a new access token (e.g., PACS smartphone app) is approved. IAM provisioning may then trigger account management workflows approvals to the necessary system owners, such as Active Directory administration, Office365 administration and other application or system owners or administrators. In this way, account management workflows are not initiated until the person successfully completes the initial background check, for example.

Step 5: Integrates the user’s PACS information with LACS information, such as adding the PACs-unique identifier, apps on the smartphone other capabilities.

Step 6: If necessary, the Security Division is notified and can conduct any further adjudication.

Step 7: The new hire activates the smartphone-based “badge app” as part of the typical first day of employment. Note that de-provisioning can be integrated with the current Exit Employment application via IAM and the enrollment server (PACS).

In this pattern, we illustrate the PACS service being cloud-based, but this is not required – the PACS servers could be on-premises, in the cloud or hybrid. We also show the smartphone being adopted as the principle converged token for PACS and LACS. This is not required – the token could be a smart card, a badge, both or all three. The point is that integration of the IAM infrastructure with the PACS environment is the appropriate means to converge PACS and LACS, affording a tailored view of the each individual accessing facilities and IT systems, subject to the same provisioning, de-provisioning, governance, attestation and monitoring capabilities currently more native to LACS environments.

Governance

Governance plays an important role throughout the lifecycle of an IAM initiative, from project inception to implementation to ongoing support and enhancements. A strong governance team will help the enterprise achieve high data quality, promote application interoperability, and avoid undue risks.

Governance of the IAM infrastructure is a crucial element in managing the growth to incorporate PACS. When undertaking a PACS migration to current cloud-based, IP-centric models as we have been describing, it vitally important that the enterprise develop a detailed governance model that establishes the overall information and physical security standards, policies and principles, and ensures the PACS strategy fully aligns with the IAM strategy and  architecture.  Governance is the key to supporting the broadest range of constituency requirements, no matter how far across the globe the constituents may be.

One of the key roles of the governance team is to maintain focus, manage relationships, overcome any technical or political roadblocks, and provide leadership throughout the life of the IAM-enabled PACS-LACS environment.

Briefly, we recommend that the IAM governance committee be responsible for specific tasks and focus on the following areas:

• Enterprise role definition and usage
• Security management
• LACS (application) integration
• PACS integration
• Identity data privacy guidelines
• Schema extension likely for PACS integration
• Business process impact on identity management and physical security teams
• Integration with external organizations as necessary
• Budget and funding
• Operations issues including staffing, training and so forth

Keep in mind that IGA is an important extension of the provisioning and de-provisioning capabilities resident in a typical IAM environment. For example, as described in the TechVision report “Designing and Implementing Effective Enterprise Identity Governance and Administration Program”, we state that the goal behind IGA is simple: Ensuring appropriate access, when and where it is needed.

IGA combines entitlement discovery, decision-making processes, access review and certification with identity lifecycle and role management. IGA operates in the intersection of business process management and access automation allowing people and systems communicate with each other, fulfilling day-to-day operational needs. It focuses on the process and operational components of identity and access management. IGA is focused on addressing issues related to the mapping of business objectives to policies as well as creating a platform for the execution and administration of these policies. IGA is a bridge between the business decision makers and those that administer the technology in support of managing all aspects of governing access. To converge PACS and LACS means to extend IGA to monitor, audit and enforce physical access management as well a logical (IT) access.

Vendors of Interest

There is much happening in the PACS market with respect to migration to IP networking, multi-token ‘badging’ and integration with IAM.  In this section, we highlight a small but meaningful set of vendors who are either “all in” or appear to be heading in the integrated PACS/IAM direction. We will continue to update our clients as momentum builds in this space, new players are introduced, or existing vendors upgrade their offerings.

Brivo

Brivo, Inc. is a company providing cloud-based access control and video surveillance products for physical security and internet of things applications. Brivo was founded in 1999. In 2002, Brivo introduced cloud-based access control to the physical security market. The company is currently servicing over eight million users with Brivo OnAir focused on offering scalability and centralized security management for global enterprises. The Brivo OnAir security management system provides combined access and video management in a single cloud platform.

Figure 7: Brivo OnAir Overview

The Brivo security platform and Brivo Onair API enables customization of design and on integration with the goal of achieving a unified, centralized management solution. Through their API, enterprises can add, modify or deactivate Brivo users while within their existing identity management solution. This helps to couple physical and logical access within the same authoritative data sources, interfaces, workflows and audit trails. Additionally, out-of-the-box IAM integration with Okta, Active Directory/AAD and Google G-Suite is available.

HID

The HID Crescendo Mobile App provides strong multifactor authentication to cloud applications, VPNs, desktops, and Microsoft Active Directory. The Crescendo Mobile App can be downloaded to Android or iOS devices and behaves as a regular PKI smart card. This means that it doesn’t require specific middleware. The Crescendo Mobile App works on personal smartphones and tablets.

Customers already using HID’s ActivID Credential Management System (CMS) and Crescendo physical smart cards can extend the reach of their current deployment to serve user groups for whom a physical card may not be a suitable alternative. Crescendo Mobile is recognized by Windows 10 PCs as a regular smart card and can be used with a Bluetooth connection or with an NFC reader (when using a NFC-capable Android phone). Issuance of credentials can be performed locally on the user’s PC or remotely using the phone’s regular Internet connection.

Crescendo Mobile uses digital certificates protected by a PIN to achieve a higher level of trust. The use of asymmetric cryptography and a trusted certification authority provides protection against the theft or cloning of credentials.

iCLASS SE and multiCLASS SE mobile-enabled readers are part of the HID Mobile Access solution that offers a consistent user experience across different devices and operating systems, including iOS and Android. The readers can be configured to using a smartphone with a “tap” or utilizing HID’s (patented) “Twist and Go” gesture technology.

In January 2020, HID announced its new WorkforceID identity management cloud service. It provides a set of logical and physical identity access management applications intended to help customers address their continually evolving workforce and visitor security, compliance, and business challenges. Based on the enterprise-grade HID SAFE physical identity access and visitor management software, and experience with the 250+ organizations around the world already using it, WorkforceID is an entirely new cloud service/platform with ISO27001 certification. Conceivably, this is a game changer for HID on of the largest ‘legacy’ PACS vendors in the world.

Honeywell

Honeywell’s offerings have been around for almost 80 years resulting in PACS solutions that have been widely deployed. The company has been refreshing its offerings of late with their  web-based NetAXS controller. This controller enables users to securely manage their system over an Internet connection, resulting in lower dedicated PC or software costs and moving it into the more modern approach we’ve been describing.

Their NetAXS-123 offering supports the traditional access control services such as securing doors, managing employee access and managing sites remotely. But it also supports reporting capabilities to meet compliance requirements. It also has a browser-based interface which means there is no dedicated software required. This allows enterprises to manage the NetAXS-123 by using the embedded browser, MAXPRO Cloud’s secure cloud infrastructure, or WIN-PAK’s integrated security suite.

Honeywell’s OmniClass reader suite is a range of 13.56 MHz contactless secure smart card readers intended to provide high reliability, consistent read range and ease of installation. Readers are available in several sizes and each OmniClass reader incorporates smart card technology allowing multiple applications per physical card and optional mobile (smartphone) credential capability.

OmniClass can retrofit any Wiegand output reader, including standard HID or Honeywell proximity readers. HID’s Mobile Access platform (Crescendo, discussed above), OmniClass offers optional Bluetooth capability allowing users to use a compatible smartphone as a credential. Readers can be ordered in either mobile-ready (ready for mobile credential use except mobile keys are not loaded) or mobile-enabled (mobile keys are loaded and enabled for use with mobile credentials) configurations.

Identiv

Identiv, Inc. products, software, systems and services address the markets for physical and logical access control and a wide range of RFID-enabled applications for customers in the government, enterprise, consumer, education, healthcare and transportation sectors.

Freedom Access Control is based on a software-defined architecture (SDA) that makes it possible to change the underlying software easily without affecting the rest of the system. SDA aligns with migration from hardware-driven to software-driven architectures and the current trend to leverage IoT and cloud and is generally the direction TechVision recommends.

Centralized databases can operate independently or be connected to an IAM infrastructure, such as Active Directory, thereby converging physical access control and logical security management within the IT infrastructure.

The Freedom Access Control offering communicates over IP on an existing or dedicated IT network infrastructure. The Freedom Encryption Bridge connects the door hardware to the IT network and provides encrypted communication to servers. All system configuration, administration, and monitoring are performed using a common web browser. Freedom is typically installed on an existing network. In this way, fault tolerance and resiliency strategies that ensure network security and reliability automatically apply to Freedom.

 

Figure 9: Identiv’s Freedom Access Control Architecture

Application and database servers operate virtually or on dedicated hardware with redundant power supplies, network connections, and hard drive storage. Synchronized redundant servers can be implemented across the network to mitigate both server and network failure.

Freedom Access Control utilizes real-time data to obtain situational awareness relating to asset protection, apply policy-based control measures in response to threat and operations conditions, and share information with subscribed stakeholders (people, systems, or devices), supporting planned organizational responses for maintaining personnel safety and asset security.

Freedom natively supports unified physical and logical identity and access management and common credentialing through native support for corporate directory and IAM integration and for online authentication systems. It leverages existing Active Directory (AD) infrastructures to manage authentication and authorization of card or app user populations. This is accomplished by syncing user accounts between OUs and Groups in AD doors privileges in Freedom. Typical objects and attributes to map and synchronize are users and devices (door readers, elevators, and locking hardware). The advantage of this approach is having a unified platform that eliminates a dedicated user database of physical security. This level of IAM integration affords the following benefits:

• When a change is made in AD, it gets replicated to Freedom
• The current validity of a user and their door access is managed in AD

Lenel

Founded in 1991, Lenel launched its OnGuard security product line in 1995. Lenel has been one of the leading vendors of physical access control systems since this time. Their flagship solution, OnGuard has continued to evolve over this timeframe and most notably Lenel has focused on the integration of OnGuard with customers’ existing business systems. For example, the OnGuard system can bi-directionally exchange cardholder data with HR platforms and/or ERP systems, coordinate alarm/event data with emergency response systems, and provide/receive event information with building management, network management and third-party security systems.

OnGuard Cloud Edition is a pre-configured version of the OnGuard platform that is designed by Lenel to be rapidly deployed in the Amazon Web Services (AWS) cloud. Obviously, the intent is to streamline installation while reducing investment in server infrastructure.

By providing the means to aggregate, visualize and share security data from multiple sources, the OnGuard system attempts to help companies recognize context and analyze input from a number of simultaneous events. By aggregating information from access control, video and other sensors, OnGuard is attempting to deliver a more comprehensive ‘line-of-sight’ to all aspects of security and tries to facilitate more intelligent responses and outcomes.

From an interface and token standpoint, Lenel sells BlueDiamond, one of its OnGuard companion offerings that includes the BlueDiamond mobile smartphone app, BlueTooth/RFID readers and mobile credentials, tied together by the OnGuard cloud server. Lenel provides a great deal of information on their website, of course, but the illustration below shows how OnGuard and BlueDiamond interact.

Figure 10: Lenel OnGuard and BlueDiamond Integration

Integrating with the OnGuard platform, the BlueDiamond tools (apps, readers, etc.) can be configured to be launched, viewed and managed using the OnGuard Console—a “unified launch pad” that ties core, browser-based and third-party components of the system into one.

The OnGuard suite also comprises the Lenel Visitor Client, which is a browser-based client for managing visitor access, with an interface designed for use on a web page or tablet for visitors. The OnGuard Monitor Client is a mobile way to monitor access events and associated video via their browser-based client. This allows users to monitor live LNVR video from a tile in the client UI, customize views, view event video, and view pre-event video as well. Lenel’s User Admin Client is their module for system administrators to use a browser-based toolset to manage users in the OnGuard system.

Openpath

This Culver City, CA based physical access control vendor was founded in 2016 and has received over $27M in funding since that time. The company’s flagship product, Openpath Access, combines hardware with an app, enabling employees to enter the facilities using their smartphones.

The Openpath door reader supports multiple entry methods including Bluetooth, Smart Watch, and Key Card. Offered in both high frequency (HF) and low frequency (LF) options, the Openpath reader works with standard electrical wiring and fits in a standard gang box in order to facilitate the replacement of legacy readers or build it into new construction.

The Openpath Smart Hub is an access control unit with the capability to interface with up to four entries and up to eight readers (if also using Wiegand readers in addition to Openpath readers). The Smart Hub makes all entry decisions and includes ports for Openpath door readers, Request to Exit, Wiegand Readers, and Contact Sensors. RS-485 wiring connects the Smart Hub to the Openpath readers, and all readers and locking hardware is powered with an included power supply in the same enclosure for locations with space restrictions for wall mounted items.

The server software runs in the cloud, providing a Control Center online portal that provides administrator access to the enterprise-specific ‘secured area’. Control Center lets administrators manage users, set up facilities entries and permissions, and troubleshoot hardware. The Control Center’s cloud-based server software comes with out-of-the box connectors to Active Directory, O365 and Google G Suite. Of additional interest may be the fact that Openpath has been designed to integrate with existing legacy PACS environments, such as LenelS2, Feenics, Honeywell, AMAG, Genetec, Software House, RS2 Technologies, AXIS Communications, Avigilon, Gallagher, Kantech, C-Cure, Paxton, Maxxess, Open Options, and more.

What this level of integration to legacy PACS environments can provide enterprises is a more palatable and pragmatic approach to migration from legacy to IP-based, IAM-integrated PACS-LACS convergence – over time.

Recommendations

We have covered a number of options for integrating or converging PACS with LACS and there are many more on the horizon. This type of integration (between the physical access and the IAM foundation) has been an objective for many enterprises. While the U.S. federal government was able to enforce the deployment of PIV (personal identity verification) cards in the 2005-2010 timeframe for PACS-LACS (and the Department of Defense’s Common Access Card (CAC) even before that), the rest of the business world has been watching and waiting for secure-but-economical migration options to emerge. That time appears to have come and we recommend that our clients consider this convergence.

The pervasiveness of smartphones, IP networks, cloud services and IAM maturity has brought to bear the opportunity enterprises can embrace. That being said, there are some pitfalls and risks to consider before embarking on the journey of migration and convergence.

First, the migration aspect of an enterprise legacy PACS environment may be quite daunting. The readers, servers, badges, security personnel and the processes have likely been in place for decades. As usual, ripping out the entire infrastructure and replacing it with a modern approach (cloud, IP, smartphone, etc.) without carefully planning for migration is not recommended. Our advice is to move to this convergence in a well though out manner. Consider the migration of all key components and processes and pay particular attention to the governance model.  It is important to not open up security holes and process gaps as you are modernizing.

The better way to approach PACS-LACS convergence is to investigate and develop well thought out strategies.  Consider, for example, if your organization has any low-hanging fruit that requires a new PACS environment? Perhaps a new office in a particular region without legacy issues? That may be the smart place to establish an initial working proof-of-concept. The same may be said for an aging office complex somewhere – maybe it has been due for an upgrade for a while, and now is the time to replace it with a modernized solution similar to those we have been discussing in this report. Again – initial deployment may be considered a proof-of-concept. Learn how to migrate without disruption, develop the new policies and processes that will leverage existing IAM capabilities. This may also be an opportune time to rethink your IAM and IGA strategy…and, of course, TechVision can help you in this journey.

Another important consideration is how comprehensive a newly converged PACS-LACS can be. It can cover your entire global workforce for both physical access and logical access and also improve provisioning and deprovisioning. This is often a difficult pill for some to swallow, but chasing perfection is often a recipe for failure. Think 80/20 or 90/10 in terms of coverage. This means that you may not (possibly ever) be able to put one solution in place to work in every location around the globe. Some exceptions should be expected at the outset. Don’t let exceptions become the rule. There are many customer sites where we we’ve seen the requirement to use one badge at the UK offices and a completely different badge at the US offices. We’ve been living with this for decades. I can attest that if the aforementioned company I have been working for adopted a converged PACS-LACS environment like discussed in this report, myself and all other employees and contractors would be able to use our smartphones in both UK and US locations – where 98% of this company’s workforce resides. But the point is, don’t let perfection get in the way of significant progress.

Convergence is like a Venn diagram. Whereas before physical security was a completely separate entity within the organization from IT security, the 21^st century has brought about significant change in what we refer to as the Digital Enterprise. Being a Digital Enterprise means that over time, the enterprise migrates, converges and replaces old processes and technologies with newer, proven approaches. This means that your security team takes on a new meaning: it requires convergence of physical and logical (IT) security personnel on key focus areas such as governance, architecture, policy and process. Some staff may need to be moved from physical security to IT. A new security organization may need to take shape. Being a Digital Enterprise requires such ongoing evaluation and attenuation of the organization structure.

We hope you have found this report useful. TechVision Research feels that PACS-LACS convergence is now more implementable than ever before. If you establish a comprehensive strategy first, and endeavor to ‘never boil the ocean’, migration and convergence becomes a very realistic objective.

About TechVision

World-class research requires world-class consulting analysts and our team is just that. Gaining value from research also means having access to research. All TechVision Research licenses are enterprise licenses; this means everyone that needs access to content can have access to content. We know major technology initiatives involve many different skillsets across an organization and limiting content to a few can compromise the effectiveness of the team and the success of the initiative. Our research leverages our team’s in-depth knowledge as well as their real-world consulting experience. We combine great analyst skills with real world client experiences to provide a deep and balanced perspective.

TechVision Consulting builds off our research with specific projects to help organizations better understand, architect, select, build, and deploy infrastructure technologies. Our well-rounded experience and strong analytical skills help us separate the “hype” from the reality. This provides organizations with a deeper understanding of the full scope of vendor capabilities, product life cycles, and a basis for making more informed decisions. We also support vendors in areas such as product and strategy reviews and assessments, requirement analysis, target market assessment, technology trend analysis, go-to-market plan assessment, and gap analysis.

TechVision Updates will provide regular updates on the latest developments with respect to the issues addressed in this report.

About the Authors

Doug Simmons brings more than 25 years of experience in IT security, risk management and identity and access management (IAM). He focuses on IT security, risk management and IAM. Doug holds a double major in Computer Science and Business Administration.

While leading consulting at Burton Group for 10 years and security, and identity management consulting at Gartner for 5 years, Doug has performed hundreds of engagements for large enterprise clients in multiple vertical industries including financial services, health care, higher education, federal and state government, manufacturing, aerospace, energy, utilities and critical infrastructure.