Security and Architecture
Accelero's security mechanisms and controls — from operator authentication to the physical access control engine — from the perspective of cyber security and solution architecture.
Accelero is a physical access control platform that manages the entry and exit of people and vehicles through turnstiles, doors, gates, and elevators. Because it operates at the physical frontier of an organization's security, the platform handles security in depth: each request passes through multiple independent verification layers, and every access decision is recorded in a traceable way.
Security principles adopted
| Principle | How it materializes in Accelero |
|---|---|
| Layered defense | Perimeter (TLS), authentication, profile-based authorization, per-company isolation, and the access rules engine are independent layers — one failing does not expose the others. |
| Least privilege | Operators only see menus, actions, and data of the companies they are linked to; field devices only access the communication topics that belong to them. |
| Full traceability | Registration operations, logins, and each passage through access control generate persistent records, with author, date/time, and reason. |
| Encryption of sensitive data | Passwords with irreversible hash (bcrypt), photos encrypted at rest, and encrypted access QR Codes. |
| Security by default | Prepared statements in database access, hardened session cookies, and upload sanitization are the native behavior, not an option. |
Layered security architecture
A request to release an access — or an operator action in the system — is only served after passing, in sequence, through all control layers. Each layer has a single responsibility and can deny the operation on its own.
| Layer | Role |
|---|---|
| Perimeter | Nginx with TLS/HTTP2; communication with devices via a dedicated MQTT broker. Services isolated in containers with an internal network. |
| Authentication | Verifies who is making the request — operator (session), integration (key/signature), or device (broker credential). |
| Authorization (RBAC) | Decides what that operator can do, based on profiles and permissions. |
| Multi-company isolation | Ensures the operator only accesses data of the companies they belong to. |
| Physical access engine | Applies the physical security business rules (area, time, anti-passback, escort, occupancy, etc.). |
| Auditing | Persists the result — including the reason for a denial — for later investigation. |
Authentication and identity
Operator login combines a market-standard password hash, a complexity policy, and a series of contextual checks that go beyond "username and password".
// Operator password — irreversible hash with bcrypt
password_hash($password, PASSWORD_BCRYPT, ['cost' => 10]);
password_verify($enteredPassword, $storedHash); // constant-time comparison
// Required complexity policy
// ≥ 8 characters · uppercase letter · lowercase letter · number · special character
| Control | What it does |
|---|---|
| bcrypt hash | Passwords are never stored in plain text; the hash is irreversible and brute-force resistant. Encryption happens automatically on save. |
| Mandatory complexity | Requires uppercase, lowercase, number, special character, and a minimum of 8 characters. |
| Expiration and forced change | Passwords can require a change at the next login (new or expired password), with reuse of the current password blocked. |
| Periodic revalidation | At a configurable interval, the operator must revalidate access through a link with a random token sent by email, consumed on use. |
| Anti-brute-force protection | Each incorrect password attempt imposes a progressive delay on the server, making mass guessing unfeasible. |
| Device restriction | Optionally, the account can be tied to a specific device (device lock). |
| Time restriction | Login can be limited to allowed days of the week and time ranges. |
| Physical presence | Optionally, an operator can only log in if physically present in an authorized area — preventing remote credential sharing. |
Every login attempt with an incorrect password generates an incident recording the source IP, allowing attack patterns to be identified.
The platform already provides the foundation for federated authentication via OAuth2 / Azure AD (Microsoft Entra ID), allowing login to be integrated with the customer's corporate identity provider.
Operator account configuration, access profiles, and the first login flow are detailed in Operators and First Login.
Session control
After login, the operator's session is protected against theft, fixation, and improper concurrent use.
| Control | What it does |
|---|---|
| ID regeneration | The session identifier is regenerated at start, mitigating session fixation attacks. |
| Hardened cookie | Session cookies with HttpOnly (inaccessible to JavaScript), strict mode, and a 32-character identifier. |
| Inactivity timeout | Inactive sessions expire after a configurable period. |
| Single session per user | A module that prevents the same account from being active in two places at the same time — a new login drops the previous one. |
| Simultaneous session limit | The number of operators connected at the same time is controlled by the license, with slot allocation per company. |
Authorization and profiles (RBAC)
Access to system functions is governed by a roles and permissions model (RBAC): operators receive one or more profiles, and each profile grants a set of permissions.
| Control | What it does |
|---|---|
| Profiles and permissions | Operator → Profile → Permission structure, with the result cached for performance. |
| Menu by permission | The menu items displayed are filtered by the operator's permissions — they do not see what they cannot access. |
| Verification by action | Each sensitive action checks the corresponding permission at the entry point; failure throws a "no permission" exception. |
| Protected routes | Administrative routes pass through a middleware that requires an authenticated session. |
| Restricted database console | The direct database access tool is released exclusively to the root administrator user; anyone else receives a 404. |
| License entitlement | Modules and registration limits are enabled according to the customer's (encrypted) license. |
The definition of roles and permissions is done in the Profiles and Operators entities.
Multi-company isolation
Accelero is multi-company: a single installation serves several companies/residential complexes. Each one's data is kept segregated, and an operator only accesses what belongs to the companies they are linked to.
Each operator has a list of authorized companies. Queries of people, employees, visitors, and events are automatically filtered by that list — data from another company never enters the result, even if the operator tries to force an identifier.
| Element | Function |
|---|---|
| Operator–company link | Defines, per operator, the set of visible companies. |
| Query-level filter | Listings apply the company restriction directly in the database query. |
| Person–company link | People belong to companies; the operator's access respects that link. |
The registration and grouping of companies is in Companies.
Physical access control engine
The heart of Accelero is an engine of modular verification rules. On each credential presentation (card, biometrics, QR, plate), the decision to release or not passes through more than 30 independent rules. Just one failing is enough to deny access — and the decision always carries the reason.
Identity and credential rules
| Rule | Verifies |
|---|---|
| Card / person exists | The credential is linked to a registered person. |
| Card enabled and valid | The card is active and within the validity window. |
| Person enabled | The person's record is active. |
| Active category / registration date | The category (access profile) is valid and the enrollment is within the deadline. |
| Blacklist | Categories marked for permanent blocking bar access immediately. |
Area and time rules
| Rule | Verifies |
|---|---|
| Allowed area | The person has permission for the device's destination area. |
| Operating hours | The area is operating at the moment. |
| Time range | Day of the week, time range, holidays, and ad-hoc event windows authorize the passage. |
| Origin area | Directional flows require being in the origin area to transit. |
| Re-entry timeouts | Prevents re-entries within an interval shorter than the configured one. |
Advanced security rules
| Rule | Verifies |
|---|---|
| Anti-passback | Prevents double entry and tailgating — including for vehicles. |
| Escort / companion | Requires certain profiles to pass accompanied by an authorized escort; validates escort by category or ad-hoc, prevents self-escort, and handles vehicle escort. |
| Dual custody | Critical areas can require the simultaneous presence of two authorized parties. |
| Occupancy control | Limits occupancy by area and by company within the area. |
| Working-time control | Limits the maximum continuous dwell time in the installation. |
| Grants / clearances | Areas can require certifications/clearances, with positive logic (must have) and negative logic (must not have) and time-based validity. |
| Credits / quota | Areas can debit credits, blocking when the balance is insufficient. |
| Cold room | Limits dwell time in refrigerated areas. |
| Device state | Respects the controller's lock/emergency mode. |
| Visitor / event | Validates authorization status, closing, and visitor re-entry policy. |
When a person signals duress (e.g., a special password under threat), Accelero generates a duress incident with the person, card, and controller involved and triggers a notification — allowing a silent response to a risky situation.
Each refusal returns a specific reason code — anti-passback, outside the time range, area not allowed, occupancy exceeded, no grant, working-time control, blacklist, among others — recorded for investigation.
Each of these rules has its own page in the reference: Access Policy, Escort, Dual Custody, Working-Time Control, Credits, Passes and Cold Room.
Data protection and privacy (LGPD)
The platform handles personal data and images. The mechanisms below protect this data at rest, in transit, and throughout its life cycle.
| Control | What it does |
|---|---|
| Photo at rest | People's photos are encrypted (AES) on write and decrypted only on read. |
| Photo served with authorization | Images are only delivered to authenticated operators: they require a valid session and go through an authorization check in Nginx (auth request) before being served. |
| Upload sanitization | Every uploaded image is reprocessed to JPEG, removing any embedded malicious code; files are kept outside the web root. |
| Access QR Code | Access and invitation QR Codes carry data encrypted with a random nonce — they cannot be forged without the key and are validated against the database. |
| Irreversible password | Operator passwords in bcrypt: even with database access, they cannot be recovered. |
| Retention and purge | Automatic routines remove, by time/inactivity, logs, events, reports, photos, and inactive records — a basis for LGPD retention policies. |
| Biometrics removal | Biometric templates can be removed from the person and from the devices. |
The legal compliance aspects (data subject rights, controller/operator responsibilities, incidents) are in LGPD and Security.
Auditing and traceability
Accelero maintains distinct trails for administrative operations and for physical access events, allowing the reconstruction of "who did what, when, and with what result".
| Trail | What it records |
|---|---|
| Operations log | Creation, modification, deletion, logins, and administrative actions — with author, date/time, affected object, and details. |
| Access events log | Each physical passage: device/door, area, person, card, event type, and whether it was online or offline. |
| Login control | Record of sessions per operator. |
| Security incidents | Sensitive events, such as duress and incorrect password attempts (with IP). |
| Application log | Structured operational record (JSON format) with file rotation. |
The operational consultation of these trails is in Events, Incident Log and Incident Panel.
Communication and integrations
Communication with the operator's browser, with field devices, and with third-party systems is authenticated and, when it travels over untrusted networks, encrypted.
Field devices (MQTT)
The access controllers talk to Accelero through an MQTT broker. In production, each device has its own credential (hashed in the database) and an ACL that restricts the topics it can publish or subscribe to — one device cannot interfere with another's communication.
API and integrations
# API authentication by signature — the secret never travels over the network
GET /api.php
Authorization: {chave_publica}/{timestamp}/{nonce}/{assinatura}
# signature = hash(timestamp + nonce + secret)
# the timestamp must be within a short window (anti-replay)
| Channel | Authentication |
|---|---|
| Web / operator | TLS/HTTP2 in Nginx; session authenticated by hardened cookie. |
| Public API | Public key + secret + nonce + timestamp signed; the secret is never transmitted. |
| External integrations | Per-integration authentication middlewares (e.g., Bearer token), with constant-time comparison in the more recent integrations. |
| MQTT devices | Per-device credential + topic ACL; TLS port available. |
| Cameras / hardware | Authentication on calls to the equipment (e.g., digest auth). |
| Telegram bot | Token validation by the official library and request limiter enabled. |
The Accelero API is restricted-access (subject to contract/NDA), not public. Consult the commercial team for enablement.
Application and infrastructure security
| Control | What it does |
|---|---|
| SQL Injection protection | Database access uses prepared statements with parameter binding by default, separating code from data. |
| Errors without leakage | Exceptions are handled and translated into generic messages to the user — without exposing the stack trace or internal details. |
| Sanitized uploads | Images are reprocessed and stored outside the web root, in a non-executable directory. |
| Hardened session | HttpOnly cookies, strict mode, and identifier regeneration. |
| Service isolation | Multi-container architecture (application, database, cache, broker, auxiliary services) with a segregated internal network. |
| Restricted administrative console | Low-level tools (direct database access) limited to the root administrator. |
PHP 8.1+ with strict typing, PSR architecture with dependency injection, a custom ORM over PDO/mysqli, and orchestration via Docker Compose (Nginx, PHP-FPM, MySQL/MariaDB database, Redis/Valkey cache, and Mosquitto MQTT broker).
Frequently asked questions
How are operator passwords stored? With bcrypt hash, irreversible. Not even administrators can recover the original password from the database.
Does the system protect against password guessing attempts? Yes. Each incorrect attempt imposes a progressive delay on the server and generates an incident recording the source IP.
Is it possible to integrate login with Active Directory / Microsoft Entra ID? The platform already provides the foundation for federated authentication via OAuth2/Azure AD, allowing integration with the corporate identity provider.
Can an operator see another company's data? No. Each operator is linked to a set of companies, and queries are automatically filtered by that set, even in the face of attempts to force identifiers.
Why was a passage denied? Every denial returns a specific reason (outside the time range, anti-passback, area not allowed, occupancy, no grant, working-time control, blacklist, etc.), recorded in the audit.
What happens in a duress situation? The duress signal generates a specific incident and triggers notifications, allowing a silent response to a threat.
Are photos and QR Codes protected? Photos are encrypted at rest and only served to authenticated operators; access QR Codes are encrypted with a nonce, so they cannot be forged.
How are field devices authenticated? By an individual credential on the MQTT broker, with an ACL restricting each device's topics. One controller does not access another's communication.
Is access auditable for compliance purposes? Yes. Administrative operations, logins, and each physical passage are recorded with author, date/time, and result, in persistent trails.
Next Steps
- LGPD and Security — Legal compliance and data retention
- Standards and Protocols — Supported technical standards