Access Control Process

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.

Manage Users With Ease

With our central application, you can easily manage user access rights to various areas within your premises using the spaceOS Access Control feature.

The Role of spaceOS

spaceOS bridges the final gap in your access control system. We enable access via our platform but don't oversee the additional elements like readers, servers, and security systems necessary for the full functioning of your access control system.

The ACS Integration Process

Given the complexity of Access Control integration and the need for coordination between various parties, it's an agile process without a fixed deadline. However, spaceOS remains committed to keeping you informed about forthcoming project phases and their estimated durations. We advise launching the app without Access Control system initially, and then integrating it as a feature to enhance user engagement later.

Access Control: A Continual Process

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

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

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.

Open

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.