Service Level Agreement (SLA)

Effective Date: March 30, 2026

This page describes MultiMFA, Inc.'s ("MultiMFA", "we", "us") availability objectives and important limitations for the MultiMFA platform. It is part of our transparency with customers and is not a substitute for any separately signed enterprise agreement. Unless you have a written contract with us that says otherwise, this page applies together with our Terms of Service.

Uptime goal and third-party dependencies

MultiMFA strives for at least 99.9% monthly uptime for the application layer we operate, as described in Section 2. We work with large, industry-recognized service providers for messaging, email, hosting, networking, and related infrastructure; those vendors typically publish their own high availability standards and SLAs. We do not list vendor names on this page.

If any subprocessor or upstream network experiences an outage, degradation, or abuse-mitigation event, MultiMFA may be affected or unavailable in whole or in part, even when our own software is operating correctly. Those situations are addressed under exclusions below.

1. Scope of the service

MultiMFA includes web and API components we operate, as well as features that depend on SMS delivery, email, DNS, TLS, and the public internet. "Availability" is not a single switch: you may be able to sign in while SMS forwarding is delayed because a messaging provider or carrier path is impaired, or the site may be unreachable due to an edge or hosting issue. This SLA separates what we target for components we operate from features that depend on third-party services outside our direct control.

2. Availability objective (application we operate)

We work to keep the MultiMFA web application and core APIs that we host and run available to you, subject to the exclusions in Section 4. As an objective (not a guarantee of uninterrupted service), we target at least 99.9% monthly uptime for those components, measured as the percentage of minutes in a calendar month during which the service responds to health checks and core authenticated API operations we designate for monitoring, excluding excluded downtime under Section 4.

This objective assumes normal use in line with our documentation and Terms. It does not promise that every feature (for example SMS receipt at a specific carrier, or email arrival in a particular mailbox within a fixed time) will succeed every time—those paths include providers and networks we do not control.

We may refine how we measure uptime as our monitoring improves. If we make a material change to the measurement method, we will update this page and the effective date.

3. Features that depend on third-party services

The following capabilities are not separately warranted to meet the Section 2 percentage; they follow the operational status of the underlying services and the internet:

SMS (inbound and outbound), including MultiMFA SMS and MultiMFA SMS (Cell) when offered: Phone numbers, message delivery, and carrier routing depend on our messaging partners, cellular carriers, VoIP providers, and downstream networks. Incidents, maintenance, hardware failure, or limits on those paths may delay or prevent codes from arriving.
Email: Transactional and system email depends on our email delivery providers and on recipient mail systems. Delays, filtering, or blocks outside MultiMFA are outside our SLA.
Hosting: Our application and databases run on infrastructure from established hosting providers. Regional or platform incidents there may make MultiMFA unavailable regardless of software health.
CDN / edge: Traffic may pass through global edge and CDN services. Issues at those layers (or DNS misconfiguration) can prevent or degrade access to our site and APIs even if origin servers are healthy.

We monitor provider status where practical and will communicate widespread incidents through reasonable channels (for example support, email, or notices on the service), consistent with our Incident Response page.

4. Excluded downtime and events

The following do not count against the Section 2 objective, and we have no obligation to meet the Section 2 percentage during or because of:

Scheduled maintenance we announce in advance when reasonably practicable.
Outages, degradations, or limits imposed by any subprocessor or infrastructure partner we use (including for messaging, cellular carriers, VoIP, email, hosting, CDN/edge, or payments), or by their upstream networks.
Internet or DNS failures, denial-of-service attacks, hardware failure, carrier maintenance, third-party filtering, or issues on your networks, devices, or email/SMS providers on the receiving side.
Suspension or limits under our Terms or Acceptable Use Policy; misuse; or abuse response.
Force majeure events (for example natural disasters, war, widespread infrastructure failure) beyond our reasonable control.
Beta, preview, or non-production environments if we offer them.

5. Remedies

For standard plans offered on our website, we do not provide service credits or liquidated damages for downtime. Our commitment is to use commercially reasonable efforts to restore service and communicate about widespread issues. If you require a custom uptime commitment, service credits, or priority support, that must be agreed in a separate written agreement signed by MultiMFA.

6. Support and reporting issues

If you experience errors or outages, contact us at [email protected] or through the support options on the site. Please include approximate time, affected accounts or numbers, and what you observed (for example unable to load the dashboard vs. SMS not received).

7. Changes

We may update this SLA to reflect operational reality, monitoring capabilities, or provider changes. We will post the updated version here and revise the effective date. Continued use of the service after changes constitutes acceptance where permitted by law.