Security Model
At Fctr Identity, security is the foundational principle of our product. We designed the Portal to secure your front line against social engineering attacks without introducing new risks to your environment. This document describes our security architecture, data handling practices, and the compliance posture of our infrastructure partners.
1. Zero-Data Architecture
Fctr operates as a secure orchestration layer between your helpdesk agents and your Identity Provider (IDP). We adhere to a strict Zero-Data philosophy:
No Raw Identity Data at Rest: The Portal is designed to avoid retaining raw end-user identity records or credentials at rest as part of normal operations.
- No Admin Credentials Stored: We never request or store administrator passwords. All IDP access is handled via secure, scoped API tokens or OAuth2/OIDC flows that your organization controls and can revoke at any time.
- PII Shielding: User data retrieved from your IDP is processed in-memory for real-time verification display and is discarded at the end of the session. Limited operational records are retained separately under defined schedules.
- Native Authentication: Your IDP (Okta or Microsoft Entra ID) authenticates every Portal session. We rely on your existing identity perimeter — we do not create a separate identity store.
2. Compliance & Standards
- NIST 800-63B AAL2 Enforcement: The Portal enforces Authenticator Assurance Level 2 (AAL2) for all helpdesk operations. Agents must verify callers using strong, device-bound factors (such as Okta Verify Push with Number Challenge, Microsoft Authenticator Push/TOTP, or Temporary Access Passes) before any sensitive action can be executed.
- Structured Audit Trails: Every action performed by a helpdesk agent generates structured, PII-masked audit and request metadata retained in Fctr-managed Google Cloud services, supporting traceability for compliance reviews and internal security operations.
3. Ephemeral Compute & Logging Architecture
The Portal is hosted on Google Cloud Platform (GCP) in the United States using stateless application services and managed cloud infrastructure. This architecture provides inherent security benefits:
- No Raw Identity Data at Rest: Sensitive identity data retrieved from customer Identity Providers is processed in-memory for verification and operational workflows, then discarded when the session completes.
- Short-Lived Runtime Logs: Short-lived runtime logs support operational troubleshooting and are retained for approximately 1 day.
- PII-Masked Audit & Request Metadata: Structured audit and request metadata are retained separately for approximately 30 days using masked or hashed identifiers where applicable.
- Pseudonymous Billing Metrics: Usage-based billing records rely on hashed, non-PII identifiers and are retained for up to 3 years for billing and financial recordkeeping.
4. Least-Privilege Integration
We minimize our footprint in your environment by requiring only the exact permissions necessary:
- Narrow API Scopes: Fctr requires strictly scoped API tokens. We request only read access for user status and targeted write access for specific lifecycle actions (e.g., clearing sessions, triggering password resets, generating Temporary Access Passes).
- No Global Admin Required: The Portal does not require Global Administrator or Super Admin privileges to function. Detailed scope requirements are provided during onboarding and implementation.
- Customer-Controlled Credentials: All API tokens and OAuth2 client secrets are configured and owned by your organization. You retain full control to rotate or revoke access at any time without our involvement.
5. Granular Role-Based Access Control (RBAC)
Security extends to how your agents use the Portal:
- Permission Tiers: Customizable permission tiers control exactly what each agent can see and do, tailored to your support structure (e.g., Tier 1 read-only vs. Tier 3 full remediation).
- Backend Enforcement: Every sensitive API request is validated server-side against the agent's assigned role and active MFA verification session. UI manipulation cannot bypass backend controls.
- MFA-Gated Actions: High-risk operations (password resets, session revocations) require an active, time-limited MFA verification session before the backend will execute the request.
6. Infrastructure Security & Sub-Processor Compliance
Fctr relies on enterprise-grade infrastructure providers, each independently audited:
Google Cloud Platform (Application Hosting & Operational Storage)
| Certification | Details |
|---|---|
| SOC 2 Type II | Independent third-party audit coverage for Google Cloud infrastructure |
| ISO 27001 | Information security management certification |
Cloudflare (DNS & Edge Security)
| Certification | Details |
|---|---|
| SOC 2 Type II | Annual audit |
| ISO 27001 | Information security management |
7. Network Security
- TLS 1.2+ Everywhere: All data in transit between the client browser, the Portal, and your IDP is encrypted using TLS 1.2 or higher. TLS certificates are managed through Google Cloud managed certificate services.
- Rate Limiting: Strict rate limiting is enforced across all authentication and API endpoints to prevent brute-force, credential stuffing, and denial-of-service attacks.
- CSRF Protection: All state-modifying requests are protected with anti-CSRF tokens.
- Secure Headers: The Portal enforces HSTS, X-Content-Type-Options, X-Frame-Options, and Content-Security-Policy headers.
- IP Whitelisting: Customers may supply their corporate egress IPs, which are enforced at the application layer. Optionally, Fctr can assign a dedicated external egress IP that the customer whitelists in their Okta tenant for OAuth / token traffic, ensuring mutual network-level trust.
8. Vulnerability Management
- Static Analysis (SAST): Automated static application security testing via GitHub CodeQL (default setup, runs automatically via GitHub Advanced Security) and Snyk Code (dashboard-based scanning with tuned ignore policies).
- Software Composition Analysis (SCA): Dependency vulnerability scanning via Dependabot (automatic alerts and security update PRs via GitHub Advanced Security) and Snyk Open Source (dashboard-based monitoring across frontend and backend packages).
- Secret Scanning: GitHub Secret Scanning with push protection enabled via GitHub Advanced Security, actively blocking commits that contain supported secret patterns. Validity checks verify whether detected credentials are live.
- SBOM Generation: Software Bill of Materials generated via GitHub Dependency Graph, providing full visibility into project dependencies and their license and vulnerability status.
- Responsible Disclosure: If you discover a security vulnerability, please report it to [email protected]. We review reports promptly and respond in accordance with our internal incident handling procedures.
9. Contact Security
If you have questions about our security practices, require compliance documentation, or wish to report a vulnerability: