Security & trust
Nexus applies clear boundaries between the browser, application services and customer infrastructure.
Authenticator 2FA is recommended for every member and administrator. An unenrolled account may explicitly continue after the short pre-auth step; once 2FA is enabled, every later sign-in requires RFC 6238 TOTP verification or one single-use recovery code and cannot skip the factor.
Unique authenticator seeds use AES-256-GCM encryption with account-bound authenticated data. Accepted TOTP counters prevent replay, recovery codes are stored only as keyed hashes, and layered account plus IP limits bound online guessing.
Members can register with a confirmed email and password or explicitly choose Google registration. New accounts have no platform assignments or administrator privileges. Passwords use salted scrypt hashes; email verification and password reset use 30-minute, single-use links. Google sign-in verifies the account identity and does not replace an existing password account.
System administrator sign-in remains Google-only and requires a current server-side session, admin role and exact configured email allowlist match. Viewers and managers receive only explicitly assigned platforms; role, assignment and status changes revoke existing sessions. Administrators are strongly advised to activate 2FA.
Public, member and MCP clients never receive infrastructure credentials. Platform configuration stores explicit environment-secret references, and legacy raw values are masked for migration.
Domains, URLs, service endpoints, modules, databases and Redis records are normalized and bounded before persistence.
Only documented application hashes can be inspected or updated; unrelated and queue keys are outside the contract.
A restrictive Content Security Policy, trusted-origin checks, SameSite cookies, frame denial, no-store responses and bounded request bodies reduce browser-side attack paths.
Agent requests verify TLS, disable redirects and environment proxies, pin safe DNS resolution and reject private or reserved destinations unless explicitly approved for a deployment.
Account provisioning, role, platform access, account status, MCP registry and protected Redis changes create bounded server-side audit events without request secrets. Authentication audit and public contact records have datastore-enforced retention ceilings.
Nexus trust center
Public artifacts describe the current product boundary. Customer-specific evidence, regions, recovery objectives and subprocessors are documented in the applicable schedule.
Machine-readable application and datastore readiness.
Open ↗VERIFIED RESOURCESecurity contact and disclosure policy metadata.
Open ↗VERIFIED RESOURCETransparent GDPR Article 28 contracting and processor framework.
Open ↗VERIFIED RESOURCEPublic-site, identity and platform-data processing boundaries.
Open ↗VERIFIED RESOURCEPublic website and service-evaluation terms.
Open ↗VERIFIED RESOURCEConsent categories and current cookie behavior.
Open ↗Deployment assurance
Deployment-specific monitoring, health checks, restart policy and recovery targets are documented in the production schedule.
Backup scope, retention, restore verification and customer responsibilities are agreed for the selected datastore model.
Hosting regions, infrastructure owners and authorised subprocessors are recorded per deployment rather than generalized publicly.
Escalation contacts, evidence handling and notification duties are defined in the applicable service and data-processing terms.
Trust through precision
This page describes controls present in the application architecture. Nexus does not claim certifications, audited uptime or customer outcome metrics that have not been independently established.