Purpose and scope
This policy defines how identities are established, how access to Nexma systems and customer data is granted, reviewed, and revoked, and how privileged access is restricted to named individuals.
It applies to all production and supporting systems, to Nexma personnel and contractors, and to customer-managed access within the Nexma platform.
Principle of least privilege
Access to systems and data is granted only to the extent required to perform a specific function. Defaults are restrictive: new accounts begin with no access and are granted permissions explicitly, based on a documented business need.
Standing access to production customer data is minimized. Where possible, access is just-in-time, time-bound, and audit-logged.
Identity and authentication
Identity is established and authenticated through managed providers, not bespoke logic:
- Single sign-on — Nexma uses Clerk as its identity provider. Customer organizations can configure SSO through their preferred identity provider; Nexma personnel access internal tooling through SSO with enforced security policies.
- Multi-factor authentication — MFA is required for all administrative accounts and for any account with access to production systems or customer data. Customer organizations are strongly encouraged to require MFA for their members.
- Password handling — Nexma does not store customer passwords. Where passwords are used, they are managed by Clerk in accordance with current NIST guidance — minimum length, breach-list checking, and rate-limited authentication endpoints.
- Deprovisioning — Accounts are deprovisioned promptly when access is no longer required — typically within one business day of role change or departure. SSO removal is the authoritative deprovisioning action.
Role definitions
Nexma's authorization model is role-based and scoped to the organization, project, or resource. The following roles are defined at the organization scope:
- Organization admin — Manages organization settings, members, and billing. Can create and delete projects within the organization. Sensitive actions are audit-logged.
- Member — Can create, view, and edit projects within the organization according to project-level permissions. Cannot manage organization settings or members.
- Viewer — Read-only access to organization resources. Cannot make changes to projects or Codex data.
- Field operator — Mobile-only role used by field crews. Can update assigned work in the Codex but cannot manage organization or project membership.
Joiner, mover, leaver
Personnel access follows a documented lifecycle. Each transition has a single owner and a target SLA.
- Joiner — New personnel are provisioned with the minimum access needed for their role. Access requests follow a documented approval flow. Security training is completed before access to customer data is granted.
- Mover — When a person's role changes, their access is reassessed against the new role. Permissions no longer required are removed; new permissions are requested and approved through the standard flow.
- Leaver — On departure, all access is revoked promptly — SSO is the primary control. Hardware is returned and personal data is removed from managed devices.
Access reviews
The Security Lead performs a documented access review at least quarterly. The review covers privileged access, production data access, and service-account credentials, and confirms that each grant is still justified.
Reviews produce an audit-ready record: who has access, why, last reviewed, and any revocations triggered by the review.
Privileged access
Privileged access — direct access to production data, administrative consoles, or infrastructure — is treated as a distinct class of access with stricter controls:
- Named individuals only — Privileged access is granted to specific named individuals, never to shared accounts. The list of privileged users is small and reviewed monthly.
- Just-in-time elevation — Where feasible, access is elevated for a defined window and a specific purpose rather than held as standing access.
- Audit logging — Privileged actions are written to an audit log that the actor cannot edit. Logs are retained for the period defined in the Data Retention Policy.
- Credential rotation — Privileged credentials are rotated at least annually and immediately on personnel change or suspected compromise.
Service accounts and API keys
Machine identities used by Nexma services and by customers integrating with Nexma follow the same least-privilege principles:
- Narrow scope — Service accounts and API keys are scoped to the minimum set of operations and resources they need. Single-use keys are preferred where the use case allows.
- Rotation — Long-lived credentials are rotated at least annually and immediately on suspected exposure. Customer-managed API keys can be rotated at any time from the platform.
- Secure storage — Secrets are stored in the platform secret store and never committed to source control. Repositories are scanned for accidentally committed secrets on every push.
- Monitoring — Anomalous use of service accounts — sudden volume changes, unexpected source IPs — triggers alerts to the on-call rotation.
Session management
User sessions enforce idle and absolute timeouts appropriate to the sensitivity of the surface — shorter for administrative tooling, longer for normal product use. Customers may configure stricter session policies for their organization where supported by the identity provider.
Session tokens are stored in HTTP-only, secure cookies, and are invalidated server-side on logout, password change, and credential rotation.