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 supports password sign-in, Google sign-in and Sign in with Apple. Google and Apple sign-in only reach an account that already exists. SAML single sign-on is not available. Google sign-in rejects an email address that Google has not verified, and Apple sign-in links to an existing account by email only when Apple has verified it.
Access tokens are short-lived and renew in the background while you stay signed in. Expired or revoked tokens are refused. A platform operator can shorten session length. In the web app, the long-lived sign-in credential sits in a secure, httpOnly cookie that page scripts cannot read. The mobile app keeps its credential in the device's secure storage. Shorter sessions limit the damage of a stolen credential; they do not make theft harmless.
Passwords and two-factor authentication
Passwords are stored as salted bcrypt hashes, never as plain text. A password-reset request gives the same answer whether or not the account exists, and reset links expire quickly and work once.
Two-factor authentication uses an authenticator app, with single-use backup codes. You confirm enrolment before it becomes active. Two-factor secrets and backup codes are stored encrypted. A platform setting can require two-factor authentication for everyone; until you enrol, you can reach only the enrolment steps.
Tenant and permission checks
Every company route checks that you are signed in, that you belong to the selected company, and that you hold the permission the action needs, where it needs one. Module licences and record ownership are checked where they apply. Arche platform administrators can act in any company; that access is labelled and logged, as described below.
Inside a company, most records are narrowed to the viewer's team unless they hold the matching view_all_* permission. A manage_ permission does not widen that reach.
When an employee's termination date arrives, Arche removes their access to that company and revokes their sessions. If they are the company's last administrator, their access is kept. Memberships in other companies are not touched.
Hiding a button in the app is a convenience, not the security boundary: the server checks every request. See Roles & Permissions.
Encryption and files
Arche encrypts selected employee fields: national ID, tax ID, NSSF number, passport number and bank account number. Integration credentials and AI provider keys are stored encrypted too. Other personal fields are protected by access checks rather than field encryption.
Files are stored per company. Downloads check your session, company and permission. Links that Arche generates for a file are signed and expire: links shown in the app last a short time, and links handed out by the AI assistant last longer. Older links created before expiry was added stopped working on 15 October 2026.
HTTP controls
The server sets standard security headers, accepts requests only from configured origins, rejects or drops request fields it does not expect, and limits how many requests one address, user or company can make in a short time.
Audit and support access
Changes that people make through the app are recorded in the audit log, including changes that fail after the server starts them, along with selected report downloads. A request refused at the door, for example for a missing permission, is not recorded. Changes the server makes on its own, such as scheduled jobs and payment callbacks, are not in this log (the daily removal of applicant data is the exception: each run that removes anyone writes one entry, see Applicant Tracking), and changes made by the AI Assistant are recorded in its separate AI audit log. The log does not hold a before-and-after copy of every field. See Audit Log & Data Export.
Arche staff acting in a company they do not belong to are labelled Arche Support in the audit log. Switching into a company from the app starts a support session with a stated reason, and selected support reads are logged too. The support session is a record, not a lock: staff access does not depend on it.
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.