This guide describes controls implemented in Arche. Deployment configuration and company settings affect their operation. It is not a certification or a production security assessment.
Sign-in and sessions
Arche implements password sign-in, Google OAuth and Apple identity-token sign-in. Social-provider use depends on configured credentials and an existing account. SAML appears in settings metadata but has no implemented sign-in strategy.
| Token | Configurable default lifetime |
|---|---|
| Browser access | 1 hour |
| Mobile/bearer access | 24 hours |
| Refresh | 7 days |
| Pending two-factor challenge | 5 minutes |
| Required two-factor enrolment | 15 minutes |
The JWT strategy rejects expired tokens and single-purpose refresh/pending tokens on ordinary API requests. Setup tokens can reach only the enrolment-permitted routes. Access-token revocation is checked against the user's cutoff.
The web client normally holds access tokens in memory and renews them with an httpOnly __session cookie scoped to /api/auth. It uses SameSite=Lax and Secure in production. Remember me controls persistence. Legacy and two-factor setup flows retain limited browser-storage fallbacks.
Mobile uses bearer authentication. Remembered sessions also store a rotating refresh token in secure device storage. Cookie rotation and expiry reduce the lifetime of a credential; they do not make credential theft harmless.
Passwords and two-factor authentication
Passwords use bcrypt, with a configurable default of 12 rounds. Production startup checks the JWT secret. Password-reset requests return a generic response, and the server stores a hash of the random reset token with a 30-minute expiry.
Two-factor authentication supports TOTP enrolment, a login challenge and single-use backup codes. Enrolment must be confirmed before it becomes active. The auth service encrypts stored two-factor secrets and backup-code material.
A platform setting can require enrolment. Users who have not enrolled receive setup-scoped access until they complete it; refresh checks the requirement too.
Tenant and permission checks
Tenant routes combine authentication, selected-company membership and permissions, with module-licence and ownership checks where applicable. Platform routes, sign-in flows and signed-file links use different access rules.
TenantGuard checks the company context against the user's company memberships. It does not itself validate every route parameter; company-targeted operations need their own scope checks. Platform administrators bypass ordinary tenant membership and permission checks.
Module licensing and UI visibility are separate from operation permission. Hiding a button is not a backend security boundary. See Roles & Permissions.
Encryption and files
The application encrypts selected employee fields: national ID, tax ID, NSSF number, passport number and bank account number. Integration credentials and configured AI API keys also have encrypted storage paths. These controls do not encrypt every personal field.
Files use tenant paths. Authenticated file downloads require the applicable session/company/permission checks. Application-generated signed-file links instead use a truncated HMAC-SHA256 signature over the path and a constant-time comparison. Each link also carries an expiry inside the signed value. Links served through the API last one hour and are re-signed on every response; links handed out through the AI assistant last seven days. Links created before expiry was introduced stop working on 15 October 2026.
Local-file access checks path boundaries. Signed responses set content-type protection and private caching; unsafe inline extensions are served as sandboxed attachments. The signed route skips the general Helmet middleware so supported embedded files can render.
HTTP controls
The server applies Helmet outside that signed-file exception, configured CORS origins, and a global ValidationPipe with whitelist and forbidNonWhitelisted for validated DTO inputs. Raw objects and direct MCP calls are not automatically validated by that pipe.
Rate-limit defaults include per-IP burst windows of 50/second, 200/10 seconds and 1,000/minute, plus user and tenant tiers of 300 and 3,000/minute. The user/tenant tiers are configurable, and some endpoints have route-specific limits or exemptions. Redis configuration and availability affect whether counters are shared across instances.
Audit and support access
Authenticated mutations reaching the audit interceptor are recorded asynchronously, including handler failures, along with selected report downloads. Guard rejections do not reach it. The interceptor does not produce a record for every database write or a before/after snapshot of every field.
Platform staff acting in a company they do not belong to are labelled Arche Support. The company-switching UI starts a reason-bearing support record, one hour by default. Selected support reads are also logged; notification, health and current-profile reads are excluded.
Support-session records do not grant or revoke access. A missing or expired session does not prevent platform-admin access, and a reason can be absent when no active session exists. See Audit Log & Data Export.
AI privacy
Company redaction is configurable, uses patterns and known field names, and does not guarantee complete masking. Analytical features and audit rejection paths have additional data-retention considerations. See AI Privacy & PII Handling.