What's Access Control?
spaceOS's Access Control is a feature that provides a seamless, cardless entry for your users to your facility, be it a building, office, or specific location using only their smartphones. The user-friendly spaceOS app replaces traditional plastic access cards, offering an innovative, sustainable solution.
...
Access Control isn't a one-off product or service confined to a single address. Instead, think of it as an evolving architecture and a series of processes that integrate with the client's on-site environment and gradually expand across the facility over time.
Why Use It?
As the trend towards hybrid work models gains momentum, offices are increasingly shifting towards mobile access solutions. This transition comes as a response to the challenges associated with infrequent office visits, which often result in misplaced or lost physical access cards. By reducing lost cards, we can minimize the workload for security teams.
Mobile access introduces a more flexible, user-driven approach. Only those individuals who require office access need to generate their mobile card, unlike the traditional model where physical cards are issued to every employee, regardless of their actual need for office access. The benefits of this shift are twofold: cost reduction and a decrease in plastic use!
Glossary
In this guide, we'll be using the following terms:
Access Control (AC) - Term that we use for naming our service or the team.
Access Card - A coded employee card, usually the size of a credit card, recognizable to the access control system and read by a reader to allow access.
Access Group - A group, in which we can define access to different areas and add users to which we would like to grant or limit access. A defined set of access permissions that can be assigned to AC users to control the level of access they should have.
Access Control System (ACS) - An interconnected set of controllers that manages the entrances and exits of secure areas, granting or denying access to individuals. See also: Connector
Access point - Any door, gate, or place, to which access can be limited/granted using credentials.
Credentials- Access control credentials include encoded information (recognized by access control systems) usually consisting of proximity cards, biometrics, smart chips, and key fobs used to gain access to a location.
Deployment - A particular integration deployed to a particular client’s instance.
Guest - A person that doesn’t have access to the spaceOS platform and was invited to a space by a spaceOS Member
Identifier - The name for access credentials in the Roger VISO system.
LPR (License Plate Reader) - usually a camera that can read the vehicle’s license plate number, verify if the number should be accepted, and grant access to a parking area.
NFC (Near Field Communication) - A wireless technology that allows devices to communicate by bringing them close together. It enables contactless data exchange and is used for mobile payments, data transfers, and more. NFC works by tapping or bringing devices close to each other, allowing for quick and secure interactions.
BLE (Bluetooth Low Energy) - It is a wireless communication technology designed for low-power devices and applications. BLE allows devices to connect and exchange data wirelessly over short distances. It is commonly used in various applications such as wearable devices, smart home automation, health monitoring, and asset tracking. BLE is known for its energy efficiency, making it suitable for devices with limited power sources like sensors, fitness trackers, and other battery-operated devices.
Member - A person that has been onboarded to the spaceOS platform and has access to its various modules. See also: User
Mobile Credential - Set of tokens, credential data required to initiate mobile SDK and most often generate a mobile credential card.
Parking - An integration of an external access control system with the spaceOS application, handling only parking reservations. Usually a part of a broader AC integration.
Physical Card (Plastic Card) - A traditional, physical access credential that is used to gain access to AC-restricted spaces, usually in the form of a small plastic card. Works using Radio Frequency Identification (RFID) technology. See also: Plastic Card, Proximity Card
Reader - An access control device, usually placed nearby or an integral part of an access point.
QR - A QR code, generated after making a booking, which can be scanned by the reader to grant access to a particular space in a defined period of time.
User - An entity in the access control system that represents a person. Can have different attributes assigned to it. See also: Cardholder
Client Responsibilities
Access Control Groups | spaceOS does not manage your access control groups. The customer is responsible for managing these groups and individual access for certain users in their Access Control System. |
User Synchronization | The company admin must add and delete users from spaceOS as it is the source of truth regarding User data and operates on a one-way sync. Users created or deleted directly in your security/access control system will not be synced to spaceOS. |
Hardware Management | spaceOS manages only the link to your access control system to enable users to access your location. It does not manage hardware components like readers, sensors, or servers. |
Third-Party Software Upgrades | The customer and the software vendor are responsible for any necessary upgrades and/or fixes in the Access Control System. However, spaceOS should be informed about any changes/updates that might interfere with the integration. |
Licenses, Subscriptions, and Server Installation | The purchase and management of mobile licenses and/or user subscriptions are the customer's responsibility. Likewise, the customer, the third-party hardware company, and the internet provider share responsibility for server preparation to ensure a VPN connection. |
Parties Involved
The ACS implementation process involves several parties each carrying unique responsibilities. Here is a rundown of each stakeholder's role:
Customer: Tasked with ACS system procurement, both hardware and software. Manages third-party relationships and ensures successful installation and software configuration with third-party support.
Mobile Credential Provider: An independent software company that offers a system for issuing and managing mobile credentials.
ACS Provider: An external party that delivers ACS software and hardware for managing user access rights and controlling secured zones.
System Integrator: An external company that ensures the hardware installation and software configuration.
Hardware Provider: An external party that provides readers to be installed on objects to regulate access to read mobile credentials and communicate with ACS.
spaceOS: Responsible for user synchronization, issuance, and storage of mobile credentials within the spaceOS app.
Prerequisites for AC Integration
Prerequisite | Information |
API Access for Third Parties | The access control system must have an API that spaceOS can access for any integration. The API communication between spaceOS and the access control system is essential for the integration. |
Mobile SDK for Third Parties (if needed) | To enable mobile card access functionality, spaceOS requires integration with the reader manufacturer's mobile SDK. Note: If HID readers are installed, the access control does not need a dedicated mobile SDK. |
Bluetooth-Enabled Readers On-Site | BLE-enabled readers are necessary at the client's site for mobile card access functionality. |
Server and VPN for On-Premise Solutions | Depending on the installed Access Control system, a minimum spec server might be needed. Please note that subpar servers cannot be integrated, and the server used for ACS integration must be stable. A method to communicate with the system via the spaceOS API (VPN based) is required. |
System Access | Access to the Access Control operating system and related portals is necessary to connect the tools (spaceOS, third-party software). Admin access to external mobile credentials management platforms/portals (if applicable). Access to the demo access control system environment (if available). |
Active Licenses (system-dependent) | Purchased and active licenses should be shared with spaceOS (mobile cards). User/Mobile credentials licenses purchase - Please confirm if purchased and 3-5 of them could be shared with spaceOS. A system operator license should be available (if required for API communication). |
Access Groups | A list of Tenants with pre-existing access groups assigned is required. |
Disclaimer and Process
The decision to execute the integration lies within the purview of the technical team at spaceOS. For any decisions related to integration, it's vital to consult with the product team beforehand.
Please take note of the following: If spaceOS encounters unforeseen issues that obstruct or stall our operations - be it communication difficulties, insufficient access or licenses, incorrect software versions, or delays in hardware setup - the problem will be swiftly escalated to you, the client. Consequently, the integration process will be put on hold until the issue gets resolved. This principle applies to all stages of the integration process.
...
Phase 1 - Discovery
The discovery phase is the initial stage of integrating your access control system with building software. Here, our team:
Gathers necessary information.
Assesses integration requirements.
Identifies vital components and functionalities.
We collaborate with key stakeholders, such as facility managers, IT staff, and security personnel, to understand the unique goals and challenges of the project.
By the phase end, we will have a clear understanding of integration requirements and an initial action plan. To facilitate this, please complete the detailed questionnaire (please ask the Sales representative or spaceOS Project Manager to provide you with one).
To initiate the discovery phase, spaceOS requires:
API documentation.
A completed questionnaire.
Temporary admin access to your access control system for configuration and analysis.
Mobile licenses (subscriptions) for development and testing, as needed.
Necessary vendor documents, such as NDAs.
A device (reader) for integration testing.
Expected Outcome: Decision on the feasibility of integrating your chosen Access Control system with the spaceOS platform, based on provided materials and system verification.
Phase 2 - Scope of Work
During the scoping phase, our Technical Team outlines the project scope based on the terms agreed upon in the contract. Any potential work that falls outside of the contract's boundaries will be highlighted, with an accompanying cost overview.
This phase culminates in a clear, shared understanding between the integration team and the customer of the project's scope, goals, and deliverables. Both parties will approve and sign off on this Scope of Work (SOW) document, which will then serve as the guideline for subsequent project execution.
Expected Outcome: Customer-approved Scope of Work.
Phase 3 - Development
During the development phase, the focus is on executing integration development activities and coordinating with all necessary stakeholders. This phase can vary greatly across different projects due to unique requirements, so custom system architecture and an implementation plan are often essential. These are tailored based on the specific provider/vendor and hardware involved.
In order to facilitate a seamless process, the customer must provide all required access permissions and acquire active mobile cards (licenses) for transfer to spaceOS. It is also the customer's responsibility to manage relationships with all stakeholders and vendors throughout the project's lifecycle, as well as during the daily operations of the Access Control/Integration.
Expected Outcome: The AC system fully integrated with both the platform and mobile version.
Phase 4 - Internal Tests
During the testing phase, spaceOS and all providers thoroughly evaluate the integrated application to ensure its flawless operation and address any issues that might arise. Two types of testing are involved - online and onsite.
Potential problems might be encountered during onsite testing as it involves first-time testing with the installed hardware. However, these issues can typically be rectified through additional configuration.
The Quality Assurance team at spaceOS will execute test cases and subsequently give their sign-off on the application. Please note that testing must be feasible during standard European working hours (7am - 6pm CEST).
Expected Outcomes:
Quality Assurance team's sign-off on the application.
Resolution of all logged/raised issues.
Phase 5 - User Acceptance Tests (UAT)
The UAT phase necessitates the on-site involvement of the customer team, collaborating closely with spaceOS. It's critical that any challenges or issues discovered during the testing process be swiftly reported via the Jira portal by the customer team, providing thorough details to facilitate effective resolution.
For comprehensive testing, we highly recommend including a user group of approximately 10 people, fulfilling diverse roles such as global admin, company admin, member, and staff, in the integration testing process.
Please bear in mind that complications can arise during testing due to incomplete information provided by the vendor or customer, potentially causing delays. While we strive to minimize this risk, we cannot offer absolute guarantees.
UAT Testing Scenarios:
Onboarding of every user type into the app, including the flow for using Access Control (AC) for the first and second time.
Ensuring tenants can navigate within the building using their mobile credentials.
Verifying guests can access the building using QR codes.
Confirming guests can enter the building with the same QR codes used for parking access.
Other test cases, depending on the project scope.
Expected Outcome: The integration receives sign-off from both the customer and spaceOS.
Phase 6 - Launch & Implement
The customer is responsible for training all Access Control (AC) users on-site, including receptionists, and ensuring all aspects are thoroughly tested and approved before the launch.
If needed, the AC Team can provide a session about AC use cases within the spaceOS app.
Before the AC launch, the customer must confirm that an adequate number of licenses/subscriptions for end-users have been purchased. Every company within the spaceOS platform should align with a corresponding access group in the ACS software.
A controlled launch is crucial - groups of onboarded users should not exceed 100 to ensure a smooth process for generating mobile cards. We recommend having resources available to assist users who may encounter difficulties during onboarding.