Protect the decision point.

1. Architecture principles

Fctr operates as an identity-operations layer between authorized support personnel and approved identity services. The product is designed around four principles:

• Use the organization's identity perimeter. Operator access is authenticated through the configured identity provider rather than a separate Fctr password directory.
• Minimize customer data. Fctr retrieves identity context when needed for an active workflow and limits retained operational records to defined service purposes.
• Keep authority on the server. Browser state and button visibility never determine whether an action is authorized.
• Make sensitive activity reviewable. Security-relevant workflows generate structured audit events while excluding secrets and unapproved sensitive values.

2. Authentication & session protection

Browser authentication uses standards-based OIDC with Microsoft Entra ID or Okta. The backend validates the login transaction and remains the authority for authenticated sessions.

• Authorization Code flow with PKCE, state, and nonce protections.
• Secure, HTTP-only browser session cookies that do not expose provider access or refresh tokens to frontend code.
• CSRF protection for state-changing browser requests.
• Idle and absolute session expiration, logout revocation, and server-side session lifecycle controls.
• Fail-closed handling for invalid, expired, or tampered authentication state.

Fctr Mobile

Fctr Mobile uses your organization's existing sign-in service for device enrollment. The app uses supported device security and biometrics or permitted device credentials to protect verification actions. Fctr validates responses from enrolled devices and checks that the request and device access remain valid. Requests expire, and device registrations can be revoked. A verification result does not by itself authorize a payment, account change or other business action.

3. Verification, roles & scoped actions

Fctr separates identity proof from action authority. A successful caller challenge establishes a time-limited assurance for the selected workflow; it does not grant unrestricted administrative access.

• Supported verification methods: workflows can use supported identity-provider factors and, where enabled, enrolled Fctr Mobile devices.
• Workflow binding: verification references are opaque, short-lived, and bound to the operator, selected person, provider, and workflow context.
• Backend role enforcement: access tiers and customer policy determine which information and actions are available.
• Action reauthorization: enabled support actions are re-evaluated by the backend before provider execution.
• Provider-aware constraints: unsupported or unsafe provider/account combinations fail closed.

4. Data protection & auditability

The Fctr verification product retrieves workforce identity context for authorized workflows without maintaining a shadow workforce identity directory. It minimizes retained operational data and is designed to keep credentials, provider tokens, one-time codes, and generated recovery secrets out of logs and audit records.

Operational data

Identity context is retrieved transiently from connected services as required to perform authorized workflows. Limited protected session state, opaque workflow references, configuration, and PII-masked operational records may be processed or retained to deliver, secure, support, and audit the service without creating a persistent workforce identity profile.

Audit records

Security-relevant read, verification, factor-management, and support-action events use a versioned audit contract and a restricted field set. Human-readable labels are masked where appropriate, while approved identifiers preserve operational correlation. These records may support operational review, compliance, incident response, and cyber-insurance evidence requests; acceptance depends on the requesting organization and applicable policy.

Sensitive values

Provider tokens, authorization headers, raw cookies, session identifiers, identity documents, recovery contacts, OTP values, and generated credentials are excluded from the approved audit schema. Generated recovery values are displayed only to the active authorized workflow and are not intentionally logged.

Retention and regional configuration are documented in the applicable customer agreement or deployment documentation rather than represented as one universal public schedule.

5. Application security

• Input and configuration validation: runtime configuration and API inputs are validated against explicit schemas; invalid security-sensitive configuration fails startup.
• HTTP hardening: the application applies content-security and browser-protection headers, bounded request parsing, and no-store behavior for authentication and session responses.
• Abuse controls: authentication, protected APIs, verification workflows, and support actions use limits appropriate to the available trusted identity and abuse target.
• Safe error handling: upstream provider failures are normalized into useful categories without returning raw payloads, tokens, or internal error bodies.
• Security testing: the repository includes automated tests, dependency review, and web-application security scanning as part of the delivery baseline.

6. Infrastructure security

The production target uses Google Cloud managed services and containerized application delivery. Customer deployments are designed to use encrypted transport, managed identities, least-privilege service access, and bounded audit retrieval.

• Provider APIs and cloud data services are accessed from backend services, not directly from browser code.
• Production credentials use managed runtime identity where supported rather than embedded service-account keys.
• Audit queries are bounded by tenant, time, result, cost, and authorization controls.
• Edge protections such as a managed load balancer and Google Cloud Armor are deployment controls that must be validated for the applicable production environment.

7. Shared responsibility

Fctr secures the product boundary; customers remain responsible for their identity-provider configuration, assigned roles, enabled support actions, factor policy, operator access, connected-service credentials, and incident response obligations.

• Use least-privilege provider permissions and rotate customer-controlled credentials.
• Map Fctr roles to appropriate identity-provider groups and review membership regularly.
• Enable only support actions required by the organization's operating model.
• Review audit events and investigate unexpected verification or action activity.
• Protect enrolled factors and maintain appropriate device and identity-provider policy.

8. Responsible disclosure

If you believe you have discovered a security vulnerability in an Fctr product or service, email [email protected]. Include a clear description, affected surface, reproduction steps, and potential impact. Please do not access customer data, disrupt service, or publicly disclose an unresolved issue.