How SigSpan handles authentication, encryption, tenant isolation, and the compliance mechanics you would want from a service routing your operational alerts.
SigSpan uses magic-link passwordless authentication. Users request a sign-in link by email; the link contains a single-use, short-lived token that is exchanged for a session JWT. There are no passwords stored on the platform, which removes an entire class of credential-theft risk.
Session tokens are JWTs signed with RS256 (RSA-2048). The private signing key is held in AWS Secrets Manager and is never exposed to application code. Tokens carry only the claims required to identify the tenant and user; sensitive data is not embedded in the token payload.
Magic links expire after a short window and cannot be reused. Sessions terminate via logout in the customer portal, and are revoked server-side on idle timeout, refresh token reuse detection, or administrative action.
At rest. All customer data in DynamoDB is encrypted using AWS Key Management Service (KMS). Encryption is transparent at the AWS API layer and applies to all tables, including the message audit log.
In transit. All inbound API requests, customer-portal sessions, and outbound SMS dispatch traffic are protected by TLS 1.2 or higher. Inbound email arrives at our Amazon SES endpoint over TLS where the sending MTA supports it.
Secrets. SMTP credentials, API keys, signing keys, and third-party tokens are stored in AWS Secrets Manager and accessed at runtime by Lambda execution roles with least-privilege IAM policies. No secrets live in environment variables or source control.
SigSpan is multi-tenant by design. Every DynamoDB operation passes through a shared tenant-guard library that requires the authenticated tenant ID as a mandatory condition on every read, write, and delete. If the tenant-ID condition is missing, the operation fails closed at the database level.
This is intentional defense in depth: even if a hypothetical bug caused JWT validation to be bypassed in an application path, the database operation itself would still fail without a valid tenant scope. The platform-admin role used for operational support is separately scoped and does not have a customer-facing path.
SigSpan handles the operational mechanics of US TCPA compliance for you — but it does not relieve you of the legal obligation to send only to recipients who have given valid consent. We provide the plumbing; the consent decisions are yours.
STOP / UNSUBSCRIBE handling. When a recipient replies with STOP, UNSUBSCRIBE, CANCEL, END, or QUIT, that number is added to a per-tenant suppression list. Subsequent messages to that number are not dispatched. This is automatic and required by both carrier policy and TCPA.
Consent records. Every recipient added to a tenant carries a consent record — timestamp, source, and method. These records are retained for the lifetime of the tenant relationship and are accessible via the customer portal.
What this does not cover. SigSpan does not currently hold any third-party compliance certifications (SOC 2, HIPAA, ISO 27001, PCI). If your use case requires one of these, please get in touch before signing up so we can discuss what is feasible.
Every message processed by SigSpan generates an audit record covering receipt timestamp, sending address, recipient, dispatch outcome (delivered, suppressed, or failed), and downstream provider response code.
Audit records are retained for 30 days in Amazon CloudWatch Logs and are accessible via the customer portal. If you need a longer retention window for compliance reasons, contact us — extended retention is a per-tenant configuration.
AWS WAF sits in front of the customer-facing API to provide baseline DDoS and request-shape protection. Application-level rate limiting is enforced per-tenant on the dispatch path.
If you believe you have found a vulnerability, please email admin@sigspan.com with details. Please do not file public GitHub issues for security reports. We aim to acknowledge within one business day.
For other questions about SigSpan's security posture — including data residency, retention extensions, or compliance roadmap — reach out via the contact form or see the architecture overview.
Last reviewed: 2026-05-17. This page is reviewed at least quarterly; specific implementation details may shift between reviews while the high-level posture remains stable.