Skip to content
Foxx Cyberfoxxcyber/docs

Identity & Access

How authentication, authorization, and tenant isolation work across the platform.

Covers the NIST SP 800-171 Access Control (AC) and Identification & Authentication (IA) families as they apply to the Bedrock platform.

Application authentication

  • Every user has a unique, never-reused account identifier; email addresses are unique per user type.
  • Passwords are stored only as bcrypt hashes — never in plaintext, never recoverable.
  • Failed sign-ins return a generic error, so the platform doesn't reveal whether an email address has an account.
  • TOTP multi-factor authentication is implemented and available for application users. Users enable it from their account settings; we recommend your organization require it as policy.
  • Sessions are token-based (JWT) with enforced expiry. Every API request is re-verified — there are no unauthenticated application endpoints beyond sign-in, registration, and service health checks.

We state MFA as available, not enforced, deliberately — enabling it is currently a per-user action. Organization-enforced MFA is on the product roadmap; until then, make it part of your onboarding checklist.

Authorization and tenant isolation

  • Access is role-based end to end. Role checks run in API middleware on every request — a contractor-role user cannot call assessor endpoints, and non-admin users cannot reach administrative functions, regardless of what the UI shows.
  • Every record belongs to exactly one organization, and every database query is scoped to the requesting user's organization. Cross-tenant access is prevented in the data layer, not just hidden in the interface.
  • MSP/MSSP and RP partner users see only the client organizations they have been explicitly granted.

Administrative access to the infrastructure

Foxx Cyber's own access to the AWS environment is separate from application accounts:

  • Administrative access uses single sign-on with MFA enforced.
  • There is no standing SSH or RDP access to containers; container access for troubleshooting requires per-session IAM authentication and is logged.
  • IAM roles follow least privilege — service roles can reach only the specific storage, key, and secret resources they need, with no wildcard resource grants, and no single role holds full administrative access.
  • All administrative actions are recorded in the audit trail (see Logging & Monitoring).

Last updated July 29, 2026