SIP.IO
Start free

Security Overview

Version 2026-11-06 · Effective 2026-11-06

1. Purpose

This page describes the technical and organisational measures Voxgrid Inc (“sip.io”) maintains to protect the Services and the data we process. It forms Annex II of the Data Processing Addendum. We review these measures regularly and may improve them over time; we will not materially reduce the overall level of protection.

Security is shared. We secure the platform; customers are responsible for their credentials, devices, PBXs, SIP endpoints and configuration. Our Toll Fraud page explains the controls customers should use.

2. Architecture

The platform separates a thin signalling and media edge from a cloud control plane:

  • Edge: session border controllers (Kamailio for signalling and registration), media relays (rtpengine) and IVR/queue servers (FreeSWITCH), running on Oracle Cloud Infrastructure (OCI), Google Cloud (GCP), Amazon Web Services (AWS) and regional colocation partners in the United States, the European Union, Israel and Asia-Pacific.
  • Control plane: routing, authentication, presence, call control, billing and APIs run on Cloudflare Workers and Durable Objects, with data in Cloudflare D1, R2 and KV.
  • Private control channel: edge servers connect to the control plane over Cloudflare Tunnel, an outbound-only encrypted connection. Control interfaces are not exposed to the public internet.

3. Encryption

In transit.

  • All web, console, API (api.sipio.dev/v1) and MCP (mcp.sipio.dev/mcp) traffic uses HTTPS with TLS 1.2 or higher; older protocols are disabled.
  • The webphone connects over secure WebSockets (WSS) and uses DTLS-SRTP for media.
  • SIP over TLS and SRTP are supported for customer trunks and devices that support them. Where a customer or upstream carrier uses unencrypted SIP or RTP, traffic on that leg is not encrypted, and we recommend TLS and SRTP wherever available.
  • Traffic between the edge and the control plane travels over Cloudflare Tunnel.
  • Calls handed to the public telephone network are carried according to that network’s standards, which may not include encryption.

At rest.

  • Data in Cloudflare D1, R2 (including call recordings and media) and KV is encrypted at rest by the provider using AES-256 or equivalent.
  • Secrets such as carrier credentials, BYOC trunk passwords and third-party API tokens are stored encrypted and are never returned in full through the console or API.
  • User passwords are stored using a salted, adaptive one-way hash; we never store plaintext passwords.
  • API keys are shown once at creation and stored as hashes.

4. Access control and account isolation

  • Per-account isolation: every database query that touches customer data is scoped by the authenticated account identifier, which is derived from the caller’s credential and never from user-supplied path or query parameters.
  • Scoped API keys: API keys carry explicit scopes (for example read-only CDRs, number management, messaging) so customers can grant least privilege to each integration. Keys can be rotated and revoked at any time.
  • Role-based access in the console for owners, administrators and users, and separate sub-account boundaries for resellers and white-label partners.
  • SIP credentials are per device or trunk, and customers can restrict registration and traffic to IP allowlists.
  • Operator access: our personnel access production systems on a least-privilege, need-to-know basis, through named accounts protected by multi-factor authentication. Access to customer content (such as recordings) is limited to what is needed for support or security investigation and is logged. Access rights are reviewed periodically and removed promptly when no longer needed.

5. Network and edge protection

  • DDoS protection: web and API surfaces sit behind Cloudflare’s network-level and application-level DDoS mitigation.
  • Rate limiting: API, authentication and messaging endpoints are rate limited per account, per key and per source.
  • SIP brute-force defence: the edge detects repeated failed authentication, scanning and malformed traffic and automatically bans offending IP addresses for escalating periods, in the style of fail2ban.
  • Authentication throttling: failed registration and digest-authentication attempts are throttled, and known-bad sources are cached so they are rejected cheaply.
  • ACLs and allowlists: trunks and devices can be locked to customer IP ranges; administrative ports on edge servers are closed to the internet.
  • Fraud controls: spending limits, destination restrictions, concurrent-call caps and anomaly detection on calling patterns help limit toll fraud. Prepaid wallet billing caps exposure.
  • Caller ID integrity: caller ID is validated against numbers the customer owns or has verified, and STIR/SHAKEN attestation is applied where available.

6. Logging and monitoring

  • Authentication events, administrative changes, API usage and security events are logged.
  • SIP signalling logs and edge health are collected centrally for troubleshooting and attack detection.
  • We monitor service health, error rates, traffic anomalies and capacity, with alerting to on-call staff.
  • Service status is published at status.sipio.dev.
  • Logs are protected from unauthorised modification and retained as described in the Privacy Policy.

7. Backups, resilience and disaster recovery

  • The control plane runs on a globally distributed platform with no single server to fail.
  • Edge servers are deployed in multiple regions, so traffic can be shifted if a region becomes unavailable.
  • The primary database is backed up with point-in-time recovery provided by the platform; object storage is replicated by the provider.
  • We maintain recovery procedures for loss of a region, a provider service or the database, and test them periodically. Recovery objectives are described in the Service Level Agreement where applicable.

8. Secure development and change management

  • All code changes are peer reviewed before merge.
  • Continuous integration runs type checks, linting and automated tests on every change.
  • Changes are deployed to a staging environment and pass end-to-end tests before production deployment, which is a separate, protected step.
  • Database schema changes are applied through versioned migrations.
  • Production secrets are managed separately from code and are not committed to source control.
  • Dependencies are tracked and updated.

9. Vulnerability management

  • We monitor security advisories for our dependencies, operating systems and edge software (Kamailio, rtpengine, FreeSWITCH) and apply patches based on severity.
  • We perform periodic security reviews of new features, and engage independent testers for penetration testing periodically.
  • We welcome reports from security researchers (section 14).

10. Incident response

We maintain an incident response process covering detection, triage, containment, eradication, recovery and post-incident review. Where an incident affects customer personal data, we notify affected customers as set out in the Data Processing Addendum, and within 72 hours. CPNI breaches are handled as described in our CPNI Policy.

11. Personnel

  • Employees and contractors are bound by written confidentiality obligations.
  • Personnel receive security and privacy training at onboarding and periodically afterwards, including on CPNI handling and social-engineering risks.
  • Background checks are carried out where permitted by local law and appropriate to the role.
  • Breaches of security policy are subject to disciplinary action.

12. Vendor management

We assess the security and privacy practices of vendors before engaging them and periodically afterwards, including review of certifications such as SOC 2 and ISO/IEC 27001 where available. Vendors that process customer personal data are bound by data protection terms and are listed on our Subprocessors page.

13. Physical security

sip.io does not operate its own data centres. Our infrastructure runs in facilities operated by Cloudflare, Oracle, Google, Amazon Web Services and regional colocation partners, which maintain physical access controls, environmental protections and independent certifications. We rely on and periodically review their published attestations.

14. Responsible disclosure

If you believe you have found a security vulnerability in the Services, please email security@sip.io with enough detail for us to reproduce it. Please do not access or modify other customers’ data, degrade service, place calls to premium or emergency numbers, or publicly disclose the issue before we have had a reasonable opportunity to fix it. We will acknowledge your report, keep you informed and will not pursue legal action against good-faith research that follows these guidelines.

Abuse originating from our network (such as SIP scanning or robocalls) should be reported through Report Abuse.