Defence in depth, layer by layer.
A high-level view of how BroadNet's messaging platform is structured — from the API edge to the carrier interconnects — so security is applied at every layer, not bolted on at the perimeter. This overview is deliberately non-confidential: it shows the shape of the stack, not its internal topology.
The layers, in plain terms.
Customer apps & channels
Your applications and campaigns connect over documented, versioned interfaces. Nothing about a downstream tenant is ever exposed to another.
API & SDK gateway
The public edge. Per-account Bearer access tokens authenticate every API request; per-tenant rate limiting, IP allowlisting, and an automated web application firewall (WAF) sit in front of the platform.
Messaging platform
Multi-tenant processing with per-tenant isolation, durable queueing, and delivery orchestration. State-changing actions are recorded to audit logs.
Routing intelligence
Least-cost and quality-based routing selects a legal, compliant path per destination, with grey-route detection and re-pinning if a route degrades below its service objective.
Security & firewall
Telecom-grade defences — SMS firewall, SS7 firewall, sender-ID protection, flash-call and OTP-abuse analysis — applied to BroadNet's own routes by default.
Carrier interconnects
1,000+ direct operator connections give direct binds in 86 countries, with labelled partner routes across the rest of the 200+ reached, so traffic terminates on legitimate, contracted routes.
Five defensive planes, in depth.
The numbered layers above describe the path a message takes. These five planes describe the controls that hold at every point on that path — each one designed so that a failure in one plane is contained by the next.
Edge & network
The public edge terminates TLS 1.3, absorbs volumetric abuse, and validates that a request is well-formed before it ever reaches application logic. Nothing downstream trusts the network it arrived on.
- Per-tenant and per-endpoint rate limiting with burst controls
- IP allowlisting and mutual-TLS options for SMPP and API binds
- Automated web application firewall (WAF) filtering common injection and abuse patterns
- DDoS absorption and connection-level anomaly shedding at the edge
Application & identity
Every request is authenticated and authorised on its own merits. Per-account Bearer access tokens establish identity; scoped roles decide what that identity may do; multi-tenancy is enforced in code, not by convention.
- Per-account Bearer access tokens for the API; short-lived tokens for interactive sessions
- Role-based access control with least-privilege default scopes
- Per-tenant isolation so no tenant can address another tenant's data
- TLS-encrypted webhooks for inbound DLR and MO
Data & storage
Message content, delivery metadata and audit records are held under encryption at rest with retention that matches contractual and regulatory windows. State-changing actions are written to an append-only audit trail.
- AES-256 encryption at rest across primary stores and backups
- Append-only audit logging of state-changing actions
- Data-retention windows aligned to contract and regional regulation
- Backups encrypted and tested against defined recovery objectives
Key management
Keys are generated, stored, rotated and retired inside dedicated key-management infrastructure. Application code holds references, not raw key material, and rotation does not require a service outage.
- Centralised key management with separation from application secrets
- Scheduled key rotation and prompt revocation on suspected compromise
- Separation of duties for key custody and administrative access
- Envelope encryption so data keys are themselves protected by master keys
Monitoring & response
Observability spans the whole stack rather than a single choke point, so anomalies are caught close to where they occur. A 24/7 NOC couples detection to a documented incident-response process.
- 24/7 NOC with alerting across edge, platform, routing and interconnects
- Grey-route, sender-ID-abuse and OTP-abuse analytics on live traffic
- Documented incident response with severity classes and named escalation
- Root-cause analysis (RCA) and reason-for-outage (RFO) after material incidents
Controls, mapped to standards.
A representative mapping of each layer to the control families in ISO/IEC 27001, SOC 2 and ISO 22301. It is illustrative, not the full statement of applicability — the audited control set is shared under NDA.
| Layer | Representative controls | Mapped standard |
|---|---|---|
| Edge & network | TLS 1.3, WAF, per-tenant rate limiting, IP allowlisting, DDoS absorption | ISO 27001 A.8 · SOC 2 CC6.6 |
| Application & identity | Bearer-token API authentication, RBAC least-privilege, per-tenant isolation | ISO 27001 A.8 / A.9 · SOC 2 CC6.1–CC6.3 |
| Data & storage | AES-256 at rest, append-only audit logs, retention windows, encrypted backups | ISO 27001 A.8 · SOC 2 CC6.1 / C1.1 |
| Key management | Centralised KMS, scheduled rotation, revocation, separation of duties | ISO 27001 A.8.24 · SOC 2 CC6.1 |
| Monitoring & response | 24/7 NOC, cross-layer telemetry, documented IR, RCA/RFO | ISO 27001 A.5.24–A.5.28 · SOC 2 CC7.2–CC7.4 |
| Continuity | Backups, tested recovery objectives, business-continuity management | ISO 22301 · SOC 2 A1.2 |
Mapped standards reference ISO/IEC 27001:2022 Annex A, the SOC 2 Trust Services Criteria, and ISO 22301. See Compliance for the certification list and the Trust Center to request evidence.
Encryption & key management.
Encryption is only as strong as the way its keys are handled. Data is protected in transit and at rest, and the keys that protect it live in dedicated infrastructure — separate from the application code and the data itself.
In transit
TLS 1.3 on every external interface — API, SMPP and webhooks — with modern cipher suites and certificate-pinning options for enterprise binds.
At rest
AES-256 across primary stores and backups. Message content and delivery metadata carry retention windows aligned to contract and regional regulation.
Key lifecycle
Centralised key management with scheduled rotation, prompt revocation, separation of duties, and envelope encryption so data keys are themselves protected by master keys.
Threat model & defence in depth.
Defence in depth means no single control is load-bearing on its own. For each realistic attacker goal, more than one plane has to fail before there is impact.
Credential theft or leaked API key
Least-privilege scopes limit blast radius; short-lived tokens and prompt revocation shrink the window; per-tenant isolation prevents lateral movement to another tenant.
Grey-route injection & sender-ID spoofing
The SMS firewall and sender-ID protection classify and drop illegitimate traffic before it terminates; direct operator interconnects mean legitimate traffic lands on contracted routes.
OTP-abuse / artificial inflation of traffic
Behavioural analytics and flash-call / OTP-abuse detection throttle inflated patterns at line rate before they can be monetised downstream.
Signalling-layer attacks (SS7)
The SS7 firewall inspects and filters signalling to defend against location tracking, interception and fraud attempts at the network layer.
Data exposure in transit or at rest
TLS 1.3 protects data in transit and AES-256 protects data at rest; keys live in dedicated key-management infrastructure separate from the data they protect.
Insider or administrative misuse
Role-based access control, separation of duties for key custody, and append-only audit logging make privileged actions accountable and reviewable.
Monitoring across every layer
Observability and 24/7 monitoring span the whole stack rather than sitting at a single choke point, so anomalies are caught close to where they occur. Specific tooling and alerting thresholds are shared with evaluators under NDA.
Encryption throughout
TLS 1.3 protects data in transit and AES-256 protects data at rest across the layers. Detailed key-management and control specifics are available under NDA — see the certifications for the audited scope.
Certified control detail, data-centre locations, exact recovery objectives, and internal topology are covered by BroadNet's audited scope and shared under NDA. See ISO/IEC 27001 and ISO 22301.
Where this connects.
This overview is the architectural view. The evidence, certificates and operational commitments that back it live in the Trust Center and the Compliance and Security pages.
Frequently asked questions.
Is this the complete security architecture?
No. This page is a deliberately non-confidential overview: it shows the shape of the stack and the controls at each layer, not the internal topology, data-centre locations or exact recovery objectives. Certified control detail is shared with evaluators under NDA and covered by BroadNet's audited scope.
Which standards is the platform certified against?
BroadNet holds ISO/IEC 27001 (information security), ISO 9001 (quality) and ISO 22301 (business continuity). The controls-mapping table on this page cross-references representative controls to ISO 27001, SOC 2 and ISO 22301 control families so evaluators can see how each layer aligns.
How is encryption handled in transit and at rest?
TLS 1.3 protects data in transit and AES-256 protects data at rest, across primary stores and backups. Keys are generated, stored, rotated and retired inside dedicated key-management infrastructure, using envelope encryption so data keys are themselves protected by master keys.
Do you apply your own SMS and SS7 firewalls to BroadNet traffic?
Yes. The telecom-grade defences — SMS firewall, SS7 firewall, sender-ID protection and OTP-abuse analysis — are applied to BroadNet's own routes by default, not offered only as an add-on for third-party estates.
How do I request the audited control detail?
Named control detail, data-centre locations, exact recovery objectives and internal topology are shared with qualified evaluators under NDA. Start from the Trust Center or the Compliance page, or contact the security team to request the documentation pack.