Security

Notification

In the event of a change to our security policy, you will only be notified by email if something here is removed or materially changed. If a minor change occurs involving our approach to security, or something is added, it will be added to this document but you will not be explicitly notified. Each time we change this document, we will update the date above to reflect that changes have been made.

HTTPS & Data Transit

Access to Authsignal is encrypted in transit using TLS 1.2 or higher. This includes the mobile SDK, database, requests, and responses from our API, our API documentation, our website, and our email communications. Many Authsignal services are not exposed to the internet; only our website, API, documentation and app are exposed. When we connect with third-party services on your behalf, we always force encrypted connections with API endpoints.

In order to access Authsignal, you will need to use a browser, server and mobile operating system that supports TLS encryption version 1.2 or newer. We no longer support TLS version 1.0 or 1.1 due to known flaws in the protocol that can lead to exploits. Likewise, we use a restricted set of ciphers that may block support from legacy versions of Internet Explorer and Safari. Authsignal supports current versions of Chrome, Safari, IE, Edge and Firefox that support strong ciphers.

We have automated security checks in place that would alert us to the introduction of unsafe code, connecting to our own or third-party services using unencrypted HTTP requests. This means that all data transit to and from Authsignal is encrypted while in transit, and will remain that way.

Access Control

We follow security best practices with respect to sensitive credentials and system access provisioning. Access to sensitive credentials is restricted to a small number of named personnel under least-privilege controls, with all access logged with multi-factor authentication enforced on all user accounts through our identity provider. All our internal services use zero trust networking through secure tunnels to protect access to backend services not exposed to the internet.

Change Management

We follow modern best practices for code change management. These best practices include, but are not necessarily limited to the following:

• Prior to each change being introduced into our code base, it runs through a series of automated tests
• Our automated tests assess the security, behavior and impact that the code we are introducing will have on the codebase
• We automatically check for security issues within our third-party dependencies as well as our own code
• At least one senior software engineer reviews each recommended change before it can be introduced into production
• We automatically check the structure and formatting of the code for bugs and prevent the introduction of new code that gets flagged
• We run automated tests both for individual functionality and across the bounds of our functionality in order to ensure we don’t introduce unexpected behavior to the system as a result of a change

This allows us to both move quickly, and safely. For a full list of checks and balances that exist before code changes are made, reach out to support. This means that it would be difficult to introduce bugs, performance or other regressions into the code base, protecting our customers.

Logging & Monitoring

We log all state changes that occur both within and among the systems that Authsignal integrates with, as well as user access and routine operations. This is an ongoing effort and requires continuously adapting as new services are built and deployed. We use the full suite of logging, monitoring, profiling and other tools provided by Amazon Web Services in order to ensure availability and observability for our systems. We have 24/7 on-call coverage. We are able to provide relevant details from logged interactions in the event of an issue. All Authsignal support and engineering staff are trained to use logs in order to ensure we can quickly and effectively diagnose and resolve issues.

Incident management

We provide a publicly visible status page that is updated on a regular basis in the event of an incident with our services. The most typical case is when a configuration change brings a service offline temporarily (such as a DNS disruption or other similar case). We will keep that page up to date with the nature of the issue, the impact on customer access and data (where relevant) and the timeline for resolution of the issue. In the event that your data were to be impacted, you will be notified urgently using your account email. We have followed this process since the founding of our business, and intend to continue.

Architecture

Authsignal services are built on top of Amazon Web Services. Payment processing is handled by our payment service provider, Stripe. Authsignal does not store cardholder data. We do regular security scans when new code is submitted using automated tools that will flag potential security issues in dependencies.

Customer Data

Our database is backed up continuously with point-in-time recovery, replicated to a separate AWS region with redundancy. The database itself is encrypted at rest by our key management system (KMS), meaning that even if someone was able to breach our cloud services provider, the data would require authentication from the KMS in order to be decrypted. No production data is retained on development machines. We will never sell or allow third-parties access to your data. Every action we perform is logged and accessible. We store the following personally identifiable information:

• Information we hold about our customers
• Information we process on behalf of our customers

FIDO Certified

Authsignal operates a FIDO2 Server certification, validated through the FIDO Alliance certification programme. This certification confirms that Authsignal's passkey infrastructure conforms to FIDO2 and WebAuthn specifications and interoperates correctly with FIDO-certified authenticators across platforms and devices. For organisations deploying phishing-resistant passkeys, FIDO certification provides independent assurance that the underlying server implementation meets the Alliance's security and interoperability requirements.

SOC2 Type II

Authsignal has certified its systems to SOC 2 Type II through an AICPA-accredited independent auditor who has assessed the operational and security processes of our service and our company. To receive additional information on our SOC 2 Type II compliance or to receive a copy of the report, please reach out to us at support@authsignal.com with the subject header: Authsignal SOC 2 Type II Compliance

ISO/IEC 27001:2022

Authsignal is certified to ISO/IEC 27001:2022, the international standard for information security management systems (ISMS). The certification was issued by an accredited certification body, and is valid through 2029. The scope covers the design, development, and operation of the Authsignal platform, including data handling, access controls, risk management, and incident response processes.

Support

Support cannot access sensitive business documents in your system and your approval is required to connect to your platform or manage configurations in your platform. This creates more friction for us when we provide you support, but the tradeoff is that none of us know what is happening in your platform unless you approve access to it directly by inviting us. Anyone with the ability to gain this access is trained for compliance with our security procedures, and have the same level of two-factor authentication applied to their user accounts they use in order to gain access.

Security disclosures

Visit our status page for any updates or security incident reporting.

If you have any questions, please email: security@authsignal.com‍