Presence architecture
Your systems.
A physical layer of trust.
Connect the person at the door, the account on the screen and the action awaiting approval. Presence adds a physical check to the systems your organisation already uses.
Your infrastructure.
Your control.
Your directory defines people and groups. Your applications and access controllers enforce permissions. Presence supplies the additional check at the point your policy requires it.
Directory · Identity provider
People · Keys · Verification requests
Applications · Access controllers
Permissions, approval limits, incident response and the final action stay with their accountable owners.
- 01
Define the request.
Your service identifies the action and the person who must confirm.
- 02
Make the physical check.
The person activates their Key and presents it to a compatible reader.
- 03
Return the evidence.
Presence connects the check to the request for the service to evaluate.
- 04
Apply your policy.
The service grants, rejects or escalates the action and records its decision.
Intended physical verification flow. Key and reader performance, request binding and the full operating environment require validation for the deployment.
Digital access
From sign-in
to the action that matters.
Connect Presence to a business application. Keep account permissions, privileged access and approval policy in your existing systems. Add a fresh physical check where the consequence calls for it.
Applications and sign-in
OpenID Connect connects a Presence sign-in to your application. Server-side permission and access checks remain essential throughout the session.
Documented interface · OIDCPeople and group lifecycle
SCIM 2.0 supports company people and groups. Entra ID and Okta setup guidance is available; tenant configuration and acceptance testing are part of each integration.
Documented interface · SCIM 2.0Privileged and AI-assisted actions
Define which payment, administrative change or agent action needs a person. Bind confirmation to that request, then enforce limits and approvals in the executing service.
Workflow-specific integration and validationOperations and oversight
Use Enterprise to manage company access and Keys. Agree the audit records, monitoring integration, retention and revocation behaviour needed by your security team.
Management API · Deployment-specific monitoringWhat connects today—and what needs an evaluation
The platform documents OIDC, an Auth.js adapter, SCIM and management APIs. That is software integration evidence; it is not proof that a physical Key or reader is qualified for a customer environment.
Existing sessions need explicit access checks and revocation handling. Directory provisioning does not create personal accounts or bypass enrolment. No universal connector or automatic compatibility with every enterprise product is implied.
Read the integration documentation (opens in a new tab)Physical access
One familiar action.
Across the places you protect.
Office entrances. Laboratories. Data centres. Residential buildings. Presence is being developed to bring the personal Key to controlled entry, with the building’s access system retaining the decision.
People, places and time.
Design access around employees, visitors and service teams: the right entrance, the right permission and the right time window. Joining, leaving and lost Keys belong in the same operating plan.
Built around the installed system.
Scope the reader, controller interface, lock and network together. Existing badge systems, local operation and supervised fallback need an explicit integration design.
What a physical-access evaluation needs to prove
- Compatibility with the chosen controller and door hardware, including revocation and any existing credential routes.
- Reliable completion under actual lighting, weather, mounting, accessibility and throughput conditions.
- Defined behaviour on network loss, power loss, a lost Key or a failed check. An offline Key does not mean an entire building system works offline.
- Emergency escape and local safety controls that remain independent of the Presence check.
The installed access-control path requires engineering and site acceptance. No universal retrofit, OSDP integration or reader certification is claimed.
Security · Safety · Privacy
Protect access.
Preserve safety.
A secure workflow must also work for the people who depend on it. These principles define the deployment we are working towards.
Keep emergency escape independent.
Leaving a building in an emergency must not depend on a Key, app, network or cloud service. Entry policy and emergency release need separate, locally approved controls.
Give every check a purpose.
Connect a check to a defined person, action and context. Apply least privilege, explicit expiry and revocation. Missing evidence must follow a documented policy rather than silently grant access.
Minimise the data involved.
The Key is designed for local fingerprint verification. Each integration must still map the data processed, who can see it, where it travels and when it is deleted.
Keep the person in control.
A person needs to understand and refuse a request. For AI-assisted actions, retain limits, meaningful oversight and a way to stop execution. Physical presence alone does not establish informed consent.
Lost Keys. Recovery. Accessibility needs. Outages. Misuse. A deployment decision needs evidence for these conditions, not only a successful demonstration.
A clear framework.
Across markets.
Security and privacy requirements depend on the product, the data, the sector and the installation. These are the principal frameworks to address when scoping a Presence deployment.
United States
Security governance
NIST CSF 2.0 · SP 800-63-4
Reference frameworksUse a risk-based security programme and assess the complete identity, authentication and recovery journey. A physical check alone does not establish a NIST assurance level.
What the deployment must address
For an evaluation: map controls, enrolment, revocation and recovery to the required assurance. Validate the whole integration, including the customer’s systems.
Privacy and data security
FTC Act · Section 5
Federal obligations, where applicablePrivacy promises must match actual practice. Reasonable security depends on the information handled, the risks and the operating context.
What the deployment must address
Document collection, retention, access restrictions, supplier responsibilities and incident handling. Keep public security claims supported by evidence.
State privacy rights
CCPA / CPRA · Other state laws
Applicability depends on the business and processingCalifornia and other states impose privacy duties where their scope is met. These can include notice, individual rights and restrictions on service-provider use of data.
What the deployment must address
Determine which laws apply, allocate business and service-provider responsibilities, and document requests, retention and permitted processing in the contract.
Biometric information
Illinois BIPA · State biometric laws
Applies to covered biometric processingBiometric processing needs its own assessment. Illinois BIPA includes notice, written release and retention requirements for covered private entities.
What the deployment must address
Map what the Key, reader and platform actually process. Local fingerprint verification is a design objective, not an automatic exemption from biometric law.
Safe physical access
OSHA exit rules · Local building and fire codes
Site and occupancy requirementsWorkplace emergency escape must remain available without a Key, app or cloud service. The applicable building and fire code governs the installed door system.
What the deployment must address
Have the responsible designer and installer validate emergency release, power-loss behaviour, accessibility and the requirements of the local authority.
Hardware and sector assurance
UL 294 · FCC · Sector-specific duties
Product, installation and sector assessmentAccess equipment may need safety listing and emissions authorisation according to its design and use. Healthcare, finance and government workflows have additional requirements.
What the deployment must address
Identify the exact product and deployment scope before testing or procurement. A UL listing, FCC authorisation, FIPS validation or FedRAMP authorisation is not claimed here.
Europe · European Union
EU framework shown below. UK, Swiss and other European deployments require their own jurisdictional assessment.
Data protection
GDPR
Law where its territorial and material scope appliesDefine the purpose, legal basis and data needed for each check. Build in privacy, security, retention limits and individual rights; assess biometric processing separately.
What the deployment must address
Agree controller and processor roles, any required processing agreement, international-transfer safeguards and whether a DPIA is required before the workflow starts.
Cybersecurity and supply chains
NIS2
Covered entities and national implementing lawsCovered organisations must manage cybersecurity risk and significant incidents. Supplier security, continuity and access controls form part of that assessment.
What the deployment must address
Map the service to the customer’s obligations, including incident cooperation, recovery, supplier review and evidence. NIS2 is not a product certification.
Financial-sector resilience
DORA
Financial entities and relevant ICT relationshipsFinancial institutions must assess ICT risk and third-party dependencies. The contract, incident process, resilience testing and exit arrangements matter alongside technical controls.
What the deployment must address
Scope the ICT service and the function it supports. Agree information, audit, continuity and exit provisions where required. Presence does not make an institution DORA-compliant by itself.
Secure product lifecycle
Cyber Resilience Act
In-scope products with digital elementsThe CRA addresses product cybersecurity and vulnerability handling. Reporting obligations began on 11 September 2026; the main obligations apply from 11 December 2027.
What the deployment must address
Classify the product and release, establish vulnerability and incident processes, and prepare the required conformity evidence before market placement. An offline Key is not automatically outside scope.
AI and human oversight
EU AI Act
Depends on the AI system, use and legal roleFor AI systems within scope, duties depend on the use case and risk classification. A physical confirmation can support an oversight design; it cannot replace informed human judgment.
What the deployment must address
Identify provider and deployer roles and applicable duties. Test whether the person can understand, refuse and stop the proposed action. Presence is not an AI Act compliance certificate.
Product and building safety
Applicable CE legislation · National building rules
Product and installation requirementsHardware needs the applicable conformity assessment and documentation. Physical access also depends on national fire, escape-route and accessibility rules for the installed system.
What the deployment must address
Determine the relevant EMC, electrical, radio, material and battery requirements for each product. Validate doors, locks and emergency release locally; CE marking alone does not approve an installation.
Evidence before scale
One workflow.
A reviewable decision.
Start with one application or entrance. Agree the integration, threats, data flows and safety requirements. Measure the result against the existing process before expanding.
Evaluate one workflow- DefineOwners, responsibilities and acceptance criteria.
- ConnectIdentity, permissions, checkpoints and enforcement.
- TestNormal use, misuse, outages, recovery and safe exit.
- DecideProceed, revise or stop on the recorded evidence.