Authentication & Multi-Factor Authentication Policy

1. Purpose & Scope

This Authentication & Multi-Factor Authentication Policy (“Policy”) defines the authentication requirements DataChimp Labs enforces for:

  • Workforce (internal) authentication — employees, contractors, and interns accessing DataChimp Labs systems, cloud consoles, source control, administrative interfaces, and production workloads.
  • Consumer (end-user) authentication — natural persons who authenticate into DataChimp Labs consumer-facing products, including flows that precede a Plaid Link handoff or any other third-party linking flow that handles financial or otherwise sensitive personal data.
  • Non-human authentication — services, workloads, integrations, and automations that authenticate to DataChimp Labs systems.

This Policy supplements the Information Security Policy and the Access Control Policy.

2. Policy Statement

DataChimp Labs requires multi-factor authentication (MFA) for:

  • All workforce access to DataChimp Labs identity providers, cloud consoles, source control, CI/CD, administrative interfaces, and any system that processes customer data.
  • All consumer authentication into products that precede a Plaid Link handoff. No consumer reaches the Plaid Link surface without first completing an MFA challenge in the DataChimp Labs authentication flow.
  • All privileged administrative operations, whether initiated by workforce personnel or by non-human automation acting on their behalf.

Where regulation, contract, or risk assessment requires it, DataChimp Labs uses phishing-resistant MFA factors (WebAuthn / FIDO2 hardware or platform authenticators). Where phishing-resistant factors are not yet deployable to a population, DataChimp Labs uses non-phishing-resistant factors (TOTP authenticator apps, push-approval apps, SMS, email one-time codes, or knowledge-based verification) as a compensating control. Phishing-resistant consumer authentication (WebAuthn / platform passkeys) is tracked in the security backlog for rollout to consumer surfaces; current baseline is TOTP-based MFA enforced at all authentication points.

3. Governance & Ownership

Role Responsibility
Security Lead Owns this Policy; owns authenticator selection, MFA enrollment standards, and step-up policies.
Engineering Leadership Implements consumer and workforce authentication flows; owns product-side MFA UX; owns recovery flows.
Identity Administrator Configures the IdP, enforces MFA policy across integrated applications, monitors MFA coverage and bypass reports.
Data Protection Officer Confirms consumer authentication meets applicable data protection and financial privacy obligations.
All Personnel Enroll and use assigned authenticators; report lost, stolen, or compromised factors immediately.

4. Definitions

  • MFA (multi-factor authentication). Successful authentication that requires at least two of: something you know (password / PIN), something you have (device, hardware key, TOTP seed, push-approval app), something you are (biometric bound to the device).
  • Phishing-resistant MFA. MFA factors that cryptographically bind the authentication to the requesting origin (relying party) so that a credential presented to an attacker-controlled site cannot be replayed. Examples: WebAuthn / FIDO2 platform authenticators and hardware security keys. Push notifications, TOTP codes, SMS one-time codes, email one-time codes, and knowledge-based verification are NOT phishing-resistant.
  • Non-phishing-resistant MFA. MFA factors that add a second factor independent of the password but that can, in principle, be relayed by an attacker-in-the-middle. Examples: SMS one-time codes, email one-time codes, TOTP codes, push notifications without number matching, and knowledge-based challenges.
  • Step-up authentication. An additional authentication challenge presented mid-session before a sensitive action.
  • Plaid Link handoff. The moment the consumer is presented with the Plaid Link surface to authorize connection of a financial account.

5. Consumer Authentication — MFA Before Plaid Link

DataChimp Labs requires MFA on the consumer before Plaid Link is surfaced. No consumer reaches the Plaid Link handoff without having completed an MFA challenge in the DataChimp Labs authentication flow within an active, verified session.

5.1 Current State

Consumer MFA is live and enforced today. Second factors currently in use are non-phishing-resistant:

  • SMS one-time codes to a verified mobile number.
  • Email one-time codes to a verified primary email address.
  • Knowledge-based verification challenges (identity questions and answers drawn from information the consumer has previously supplied or verified).

The consumer is required to complete at least one such factor after password authentication before the Plaid Link surface is loaded. Sessions that have not satisfied MFA cannot initiate the Plaid Link flow, and the server-side entry point for the Plaid Link token exchange refuses requests that do not carry an MFA-satisfied session token.

5.2 Additional Consumer Controls

  • Passwords must meet a strength baseline (length, breach-list check) and are stored hashed with a modern KDF (argon2 or bcrypt) at appropriate work factors.
  • Failed authentication attempts trigger rate limiting and account lockout with automatic notification to the account owner.
  • Every successful login and every MFA enrollment change produces a notification to the account owner.
  • Session tokens are short-lived, bound to the client, and revoked on password change, MFA change, or explicit sign-out.
  • Recovery flows require possession of a previously verified factor; self-service recovery cannot downgrade an account below the MFA requirements described in this Section.

5.3 Roadmap

DataChimp Labs is committed to moving the consumer population toward phishing-resistant authentication:

  • Passkeys / WebAuthn. Phishing-resistant consumer authentication (WebAuthn / platform passkeys) is tracked in the security backlog for rollout to consumer surfaces; current baseline is TOTP-based MFA enforced at all authentication points. Once enabled, consumers will be encouraged to enroll a passkey as their primary second factor, with SMS/email/KBA retained only as fallback until the population has migrated.
  • Number-matching push. Where push-approval flows are used, they will require number matching to reduce approval fatigue attacks.
  • SMS as fallback only. As stronger factors are adopted, SMS-based MFA will be transitioned to a fallback role and eventually retired for primary use, consistent with NIST SP 800-63B guidance.

Milestones and their target dates are tracked in the security program roadmap and reviewed at each Security Steering group meeting.

6. Workforce Authentication — Phishing-Resistant MFA

Internal workforce authentication is held to a stronger standard than consumer authentication.

  • Phishing-resistant MFA is required for all workforce access to:
    • The corporate identity provider itself.
    • Cloud console access (AWS Organization, per-account sign-in).
    • Source control (repository administration, org-level access).
    • CI/CD administrative interfaces.
    • Production administrative consoles and databases.
    • Any system holding customer data at Confidential or Restricted classification.
  • Approved factors are WebAuthn platform authenticators and hardware security keys enrolled through the corporate IdP. TOTP is permitted only as a temporary enrollment factor during onboarding and is retired once a phishing-resistant factor is enrolled.
  • SMS is not accepted as an MFA factor for workforce authentication.
  • Number-matching push is accepted only where phishing-resistant factors are not yet supported by the target system, and only with an approved, time-limited exception.
  • Device binding. MFA factors are bound to a workforce-managed device or to a hardware security key issued to the individual. Personal devices are not used to hold workforce MFA factors except where the corporate identity platform enforces mobile device management posture checks.
  • Break-glass accounts carry hardware-key MFA stored in a physical safe with a documented dual-control checkout procedure.

7. Non-Human Authentication

Non-human principals (services, workloads, CI/CD runners, external integrations) do not use MFA in the human sense. Their authentication is addressed in the Access Control Policy Section 7 and includes:

  • OAuth tokens with scoped grants and short lifetimes.
  • TLS client certificates (mutual TLS) issued from an internal CA.
  • Workload identity federation (for example, GitHub Actions OIDC to AWS IAM roles) for pipeline access.
  • IAM roles for workloads (EC2, Lambda, ECS, EKS) providing short-lived, rotating credentials.

Long-lived non-human credentials, where unavoidable, are vaulted, rotated, inventoried, and monitored.

8. Step-Up Authentication

Certain sensitive actions require an additional authentication challenge mid-session, even when the session already satisfies baseline MFA:

  • Changes to authentication settings (password, enrolled factors, primary email, mobile number).
  • Initiation of new financial connections, including Plaid Link.
  • Elevation of consumer or workforce entitlements.
  • Export of Confidential or Restricted data.
  • Administrative actions in production consoles.

Step-up challenges prefer phishing-resistant factors where the population has them enrolled.

9. Session Management

  • Sessions are short-lived, bound to the client (device, user agent, IP-derived signals used as risk inputs), and revocable centrally.
  • Continuous evaluation re-scores session risk during use; anomalies (impossible travel, sudden privilege use, new device) trigger step-up challenges or session termination.
  • Sign-out and password / factor reset invalidate active sessions across federated applications.

10. Logging & Monitoring

  • All authentication events — successes, failures, MFA enrollments, MFA challenges, step-up outcomes, session invalidations — are logged to the centralized log store.
  • Anomaly detections (velocity, geography, factor churn, push-fatigue patterns) generate alerts routed to on-call engineers.
  • MFA coverage is monitored continuously; identities missing required MFA are reported and remediated per the SLAs in the Information Security Policy.

11. Exceptions

Any deviation from the MFA requirements in this Policy — for example, a system that cannot yet support phishing-resistant workforce MFA — requires a documented risk acceptance signed by the Security Lead, a compensating control, and a defined expiration date. Exceptions are tracked in the risk register and reviewed at each Security Steering group meeting.

12. Review Cadence

This Policy is reviewed by the Security Lead at least annually and whenever there is a material change to the authentication architecture, the identity provider, the consumer product, the regulatory landscape, or the organization. The next scheduled review date is recorded in the front-matter of this document.

13. Enforcement

Compliance with this Policy is a condition of employment or engagement with DataChimp Labs. Attempted circumvention of MFA, sharing of authenticators, or unauthorized changes to authentication configuration may result in disciplinary action up to and including termination, and, where appropriate, referral to law enforcement.

14. Approval & Version History

Version Date Author Change
1.0 2026-09-01 DataChimp Labs — Security Initial issue of the Authentication & MFA Policy.

Approved by: CTO, DataChimp Labs (signature on file with the Security Lead).

Contact. Security questions about this Policy should be directed to security@datachimplabs.com. Postal correspondence: DataChimp Labs, 4507 N 189th St, Elkhorn, NE 68022, USA.

Copyright © 2026 DataChimp Labs. Public Trust Center.