A Device-Centric Identification & Access Architecture for Security Integrators
Identification and access workflows can be implemented without deploying a full enterprise ACS platform or a cloud-hosted biometric system.
In many controlled-entry environments, the operational requirement is specific:
- Identify defined individuals
- Trigger structured response
- Issue time-bound credentials
- Maintain audit visibility
- Preserve human oversight in escalation decisions
The frp®hospitality App, developed by FRP®, provides a device-centric identification and access framework designed to operate without vendor-managed cloud infrastructure.
This article focuses on three core application domains within the broader architecture.
Architecture Overview
During installation of the frp®hospitality App, configuration occurs in two steps:
- Selection of operating mode:
- ACK (Access Control Kiosk) – Android-only checkpoint device
- RAU (Remote Admin Utility) – available on iOS and Android
- Selection of one of six predefined deployment profiles.
Each device is configured during installation for a specific operational role defined by the selected mode and deployment profile.
The Android device operates as a purpose-configured endpoint that may function as:
- Identification terminal & operator dashboard
- Access validation checkpoint
- Punch Clock
Configuration is scenario-driven and defined at installation.
Device Provisioning & Industrial Kiosk Configuration
Provisioning of Android devices into controlled kiosk units is performed using a dedicated external configuration utility provided by FRP®.
The provisioning tool is available for:
A link to the utility is provided within the frp®hospitality App and on the official website.
This external tool allows administrators to configure Android devices into controlled operational endpoints by:
- Restricting system-level access
- Locking the device into ACK mode
- Preventing unintended application usage
- Enforcing controlled runtime behavior
Provisioning is typically performed once during deployment and does not require ongoing reconfiguration under normal operation.
The result is a purpose-configured checkpoint device rather than a general-use smartphone.
Local Processing & Operational Continuity
All identification and access decisions are executed locally on the Android device.
This architecture provides:
- Immediate event generation
- Deterministic response timing
- No dependency on cloud round-trip for validation
If internet connectivity is temporarily unavailable:
- Identification continues
- Access validation continues
- Events are logged locally
- Synchronization resumes automatically once connectivity is restored
Core checkpoint functionality does not depend on continuous internet availability.
Core Application Domain 1: Identification with Operator-Confirmed Escalation
The frp®hospitality App supports video input via:
- Standard RTSP camera streams
- The built-in Android device camera
RTSP support allows integrators to continue using the customer’s preferred camera vendors without introducing a parallel camera ecosystem.
The ACK unit continuously analyzes the video stream and performs local classification against configured lists.
When a match occurs:
- A color-coded dashboard card is generated
- Example: orange = Attention, green = VIP
- A distinct audio alert can be delivered to a Bluetooth headset
- Optional TTS can read the profile headline
- The detection is logged locally
- The event is synchronized to RAU (based on configuration)
Detection Logging & RAU Visibility
If logging is enabled, detection events are stored locally and synchronized to RAU.
Configuration allows selection of what is pushed to RAU:
- All detections
- Selected lists
- Specific categories (e.g., Attention only)
Push to RAU provides centralized visibility and is not inherently escalation. Escalation behavior depends on the customer’s SOP.
Manual Confirmation & Escalation
The frp®hospitality App follows a human-in-the-loop model.
After receiving an alert, the operator:
- Opens the alert card
- Reviews the reference profile image
- Compares it with the detection image
- Visually confirms the individual on-site
Only after confirmation does the operator manually trigger escalation.
Manual escalation sends notifications to configured response channels, which may include:
- Google Chat (Spaces)
- Telegram
External channels receive only manually confirmed events.
Automated classification supports awareness. Escalation remains a deliberate human decision.
Core Application Domain 2: Session-Based Access Credentials (RAU → ACK Model)
The system operates under a distributed model:
- RAU manages configuration and credential issuance
- ACK performs local validation at the checkpoint
Time-bound QR credentials are issued through RAU.
A credential can be created in seconds by entering the guest’s email address, typically sourced from a scheduled calendar event or booking record.
Upon creation:
- A unique session-based QR credential is generated
- A defined validity window is assigned
- Access scope is linked to a specific checkpoint or zone
The credential is delivered via email and can be stored in Apple Wallet or Google Wallet.
Validation is executed locally at the designated ACK device.
Credentials automatically expire outside the configured time window and do not require persistent vendor cloud connectivity.
For internal personnel, optional FaceKey-based access logic can be used.
Core Application Domain 3: Visual Punch Clock & Accountability
The same architecture can operate as a visual time and attendance system.
Features include:
- Face-based check-in and check-out
- Photo-verified logs
- Exportable audit reports
Processing remains local.
Data remains under customer control.
All events are visible in RAU for centralized review.
RAU provides:
- Device management
- Access list configuration
- Log review
- System settings control
Management and synchronization occur through the customer’s own Google Cloud infrastructure using Google APIs.
There is no vendor-operated backend.
A dedicated service Google Account may be used:
- Standard free Google account
- Google Workspace account
- Multiple accounts for structured organizational separation
Data storage:
- Encrypted locally on each unit
- Optionally stored within the customer’s Google Cloud
Synchronization between devices uses AES-256 encryption.
Data Governance & Vendor Access Model
The architecture is intentionally designed to prevent vendor-side passive access.
- FRP® has no access to customer operational or biometric data by default.
- FRP® has no access to device debug logs by default.
- Debug logs can only be exported or shared upon explicit customer action.
There is no vendor-hosted biometric database.
Operational control remains entirely with the customer.
Deployment Considerations
A pilot deployment does not require:
- Dedicated server infrastructure
- VMS dependency or VMS integration
- Vendor cloud onboarding
A Google Pixel device running the frp®hospitality App in ACK mode can be introduced alongside existing CCTV and lock environments.
External RTSP cameras are optional.
Device-native camera input can be used where appropriate.
The same architecture scales from a single checkpoint to distributed multi-device environments managed via RAU.
Technical Discussions & Partnerships
Security integrators evaluating identification workflows, session-based access, or distributed checkpoint accountability are welcome to initiate a technical discussion.
For partnership inquiries or documentation requests: partnership.form@frp.ai
