At a glance
Summary
Web authentication
Passkeys, TOTP, email OTP, backup codes and second-factor lockout controls are supported by the web authentication service.
Native devices
Crewzon may offer passkeys and local device authentication on supported devices and builds.
Service safeguards
Rate limiting, uploads, monitoring and provider controls depend on the relevant configuration.
Report an issue
Send responsible security disclosures to security@crewzon.com.
Overview
Crewzon uses technical and organisational measures intended to protect the service and the information it handles. Security depends on Crewzon, its service providers, customer configuration, user behaviour and the devices and networks used to access the service. No internet-connected service can guarantee absolute security.
1. Account Authentication
Crewzon's web authentication supports:
- passkeys, with user verification required by the authenticator;
- time-based one-time passwords through an authenticator app;
- one-time codes sent by email as a second-factor option;
- single-use backup codes for account recovery; and
- temporary lockout controls after repeated failed second-factor attempts.
The availability of an authentication method may depend on the account, browser, device, operating system and service configuration. When password sign-in is used, the authentication service processes and stores password credentials in hashed form rather than as readable passwords. Authenticated access uses managed sessions, and server-side checks require a valid user and Business Account before protected workspace data is returned.
Passkey private keys remain with the user's authenticator and are not received by Crewzon.
2. Native App and Device Authentication
On supported devices and builds, Crewzon may offer passkey sign-in and a local app lock. These controls depend on the operating system, device capability, installed build and configuration.
On supported devices and builds, the operating system may use Face ID, Touch ID, Android biometrics or a device passcode to unlock a passkey or local app lock. Crewzon does not receive the user's fingerprint, face image, biometric template, device passcode or passkey private key.
Users should keep their devices updated, use a device screen lock and remove Crewzon access from lost, shared or retired devices.
3. Access and Data Protection
Crewzon's current web application includes:
- role and Business Account checks intended to keep workspace access within the correct tenant;
- HTTPS/TLS for supported public web traffic;
- browser security headers, including content-security, frame, content-type, referrer, permissions and transport-security policies;
- validation of supported attachment types and declared file size before a presigned upload is authorised; and
- restricted storage keys and authenticated server checks when uploaded job records are created.
Some protections depend on the enabled service and its configuration. Upstash Redis supports distributed rate limiting where enabled, Cloudflare R2 supports file storage, and Sentry supports error monitoring and release reporting where enabled. Email, SMS, push, payment and other integrations also depend on their providers and the services enabled for the Business Account.
4. Monitoring and Incident Response
Crewzon records operational, authentication and application information needed to run, troubleshoot and protect the service. Where monitoring is configured, alerts and diagnostic reports help identify errors and unusual conditions.
Crewzon will take reasonable steps to assess, contain and remediate suspected security incidents according to the circumstances and available evidence. Crewzon handles notifications under applicable law and the Data Processing Addendum. Security controls and incident handling are reviewed as the service changes.
5. Customer Responsibilities
Business Accounts and users are responsible for:
- using unique credentials and protecting access to email and authenticator accounts;
- storing backup and recovery codes securely and separately from the device used to sign in;
- not sharing passkeys, one-time codes, backup codes or active sessions;
- assigning the least access each user needs and promptly removing former staff and contractors;
- checking account and workspace activity and reporting suspected unauthorised access promptly; and
- securing devices, browsers, networks, integrations and exported data outside Crewzon.
Crewzon will never ask a user to send a password, one-time code, backup code or passkey private key by email or support message.
6. Responsible Disclosure
Send suspected vulnerabilities or unauthorised-access reports to security@crewzon.com. Include enough detail to reproduce or investigate the issue, avoid accessing or changing other people's data, and do not disrupt the service. Crewzon will acknowledge and assess reports as operational capacity permits.
This page describes current and feature-dependent safeguards. It is not a certification, audit report or guarantee that every control is available in every build or deployment.
7. Retention, Encryption and Recovery
Crewzon's data lifecycle separates operational business data from restricted billing, legal and security evidence. The Data Retention Schedule describes the record classes and reasons; a legal hold can suspend their disposal. Closing or archiving a business does not itself mean that deletion has completed. The signed-in retention page reports whether automatic expiry is enabled.
Protected tenant fields and files use application-level envelope encryption with business-scoped keys. Some identifiers and operational metadata remain available to support access control, routing and data management; this is not a claim that every database column is encrypted. Key access is separated from database storage. Records of destroyed business keys are kept separately from the operational database so that restoring an older backup does not restore access through a destroyed key. Separately retained compliance evidence does not use the destroyed operational key.
Uploads use quarantine and scan-state controls before protected file access is allowed. A successful scan reduces risk; it does not guarantee a file is harmless. Storage, scanner and key-service availability are deployment dependencies.
Recovery procedures keep restored databases, replicas and file namespaces isolated until current destruction, expiry and hold information can be verified. An old backup's records alone cannot authorise its return to service. Recovery requires current authorisation and verification of the relevant provider and deletion information; a previous successful check does not replace those requirements. Recovery may remain unavailable if these conditions cannot be met. Crewzon does not guarantee that every historical copy can be restored.