Security & Trust

Dialplane is a multi-tenant platform for telecom provisioning. Our customers are service providers; their customers are the subscribers whose configuration moves through our API. We design and operate the service with defense in depth and with the assumption that the most sensitive object in the system is a customer credential.

This page describes the controls that are in place today. We will update it when the controls change.

BroadWorks user passwords are the highest-value secret you can give us. We treat them accordingly.

• Never written to our database at sign-in. The BroadWorks password you sign in with is held only in your encrypted session. A BroadWorks service-account login you choose to save for scheduled jobs, and integration credentials such as a SurgeMail admin login, are stored encrypted with AES-256-GCM.
• Encrypted at rest during an active session. The credential a session needs is stored encrypted with AES-256-GCM and exists only for the lifetime of that session.
• Redacted in logs and audit records. Password, passcode, and similar fields are replaced with a redaction marker before any record is written. Operators cannot read them internally.
• Never returned in API responses. No endpoint, MCP tool, or diagnostic surface returns a plaintext password.

Every request is bound to a tenant at authentication time. All reads and writes are scoped to that tenant. Cross-tenant access is not a configuration choice. It is prevented by construction.

• Programmatic access uses prefixed, revocable API keys compared in constant time to resist timing attacks.
• Tenant admins can issue API tokens with operation scopes that limit which tools and operations each token can use. A token can be full tenant access, read-only, or CDR-only. An API token can also be limited to specific service providers or groups, and every operational BroadWorks command is checked against those limits before it is sent. A limited token cannot use raw OCI passthrough, the change history API, the standalone SurgeMail tools, the trunk capacity report, or account administration. These limits apply to API tokens and to sign-ins through the OAuth connector, which carry the limits set on their connected admin login.
• Scope policies can cap access by BroadWorks login type. The runtime intersects the login-type policy with the token or OAuth scopes, so the most restrictive side wins.
• Scope denials are recorded for review, making it possible to tune policies without guessing which route or tool was blocked.
• Browser-based and agent-based access uses OAuth 2.1 with PKCE.
• Access tokens are short-lived. Refresh tokens rotate on every use, and reuse of a consumed refresh token invalidates the session.
• CSRF protection is enforced on the login surface.

Changes made through Dialplane's workflow, REST and MCP write operations are recorded when they succeed, with the time, the tenant, the operation, the target, and the outcome. Where the operation reads the resource, the record also holds its state before and after the change. Sensitive fields are redacted in that record. Raw OCI commands sent through the passthrough interface are not recorded. Each record made during a request also holds the login that made the request and the source IP where available, the API token where one was used, and a request id that matches the X-Request-Id header on the response.

Dialplane can coordinate adjacent systems, such as SurgeMail voicemail. Those integration actions use the same tenant scoping and audit model as BroadWorks workflows.

• SurgeMail admin credentials are stored as encrypted integration credentials, not plaintext configuration.
• Mailbox passwords used for provisioning or callback updates are redacted before operation records are written.
• If an integration side effect fails after the BroadWorks action succeeds, the failure is recorded as an integration audit result instead of hiding the partial state.

• Deleting a service provider, group, or reseller is permanently disallowed through the API.
• Rate limits apply per tenant and per source IP on authentication surfaces.
• Commands are built from typed schemas of the BroadWorks interface. A command name sent through the passthrough interface is checked against that schema registry. A registered command is rendered from its schema where possible, and any other command is rendered only when its name and field names are well formed. Every command parameter value is escaped before it is sent, and raw client-supplied XML is never forwarded.

Dialplane is pursuing SOC 2 Type II. The observation window is underway. When the audit concludes, the report will be available to customers under NDA on request.

Our controls are aligned today with the SOC 2 Trust Services Criteria for security and confidentiality.

A Data Processing Addendum (DPA) is available on request from support@dialplane.com.

Dialplane relies on the following vendors to deliver the service. This list is current as of the effective date above and will be updated when it changes.

If you believe you have found a security issue in Dialplane, please email support@dialplane.com.

• We will acknowledge receipt within three business days.
• We will not pursue legal action against good-faith researchers who follow a coordinated-disclosure process.
• We will credit reporters on request once an issue is resolved.
• Dialplane does not currently operate a paid bug bounty program.