A private deployment is usually described in terms of where the hardware sits, which is the least interesting part of the question. What makes a deployment private is where the message record lives, who can reach the management interface, and whether the traffic path leaves your network at any point other than the carrier.
This guide covers the boundary rather than the hardware: how to decide where the server sits, what controls belong on the management path, how to restrict who can send, what retention a private deployment needs, and what privacy does not cover even when the server is entirely yours.
What makes a deployment private rather than merely on-premise?
Control of the record and the access path.
A server in your own rack that forwards every message to an external analytics service is not private in any sense that matters.
Three properties define the boundary. The message record is stored on infrastructure you control, and is not replicated to a third party as a condition of sending. The access path is reachable only through authenticated routes you define, rather than through a vendor portal. And the traffic path leaves your network only towards the carrier, not through an intermediary service that logs it.
Each property is verifiable, which is what makes the word useful rather than rhetorical. Producing a data-flow diagram that shows every place a message or its metadata is stored — including logs, exports, backups and any analytics integration — is the practical test. A deployment that cannot produce one has not established where its data goes, and the gap is usually an export nobody documented.
Where should the server sit on the network?
On its own segment, with defined routes in and out.
Placement is a network decision, and the arrangement determines whether a fault can be diagnosed without taking the deployment down.
Three principles apply. Keep the gateway and the application that drives it on a dedicated segment, so that unrelated traffic cannot affect the messaging path. Define the egress route explicitly, because a device that can reach anything can be reached in ways nobody intended. And separate the management path from the traffic path, so that administrative access does not depend on the same link that carries messages.
Where the deployment spans sites, apply the same arrangement at each rather than extending a single flat network. A flat network makes every site part of one failure domain, and it makes attribution of a fault harder because the path is not bounded by anything.
The internal addressing used on the management segment should follow the private ranges defined in RFC 1918, and the translation behaviour on the path towards the carrier is described in RFC 3022. Both are worth referencing when the arrangement has to be stated in a security review.
How should the management interface be reached?
Through an authenticated path in front of it.
The management interface is an administrative surface attached to infrastructure that sends messages on your behalf.
Three options are common and they are not equally good. Direct exposure places the console within reach of internet-wide scanning and is the least defensible. A management VPN places it on a private network reachable only through an authenticated tunnel, at the cost of a client configuration for each administrator. An outbound-only tunnel lets the device initiate the connection, removing the need for any inbound firewall rule, which is the strongest option for sites whose network edge you do not control.
Whichever path is used, credentials should be individual rather than shared, because a shared administrator login makes every action unattributable. Where the console cannot enforce that, the path in front of it must. Current authenticator guidance, including treatments of password handling and throttling, is published in NIST SP 800-63B, and the transport security expectations that apply to the path are described in NIST SP 800-52 Revision 2.
How do you control who can send?
Authenticate the sender, not just the connection.
A private deployment is one where every message can be attributed to an application or a person.
Three controls are worth configuring. Per-application credentials on the API or protocol interface, so that a message can be traced to the system that submitted it rather than to the device. Per-port or per-group policy, so that an application can send from its own numbers and not from the estate. And submission logging, recording which credential submitted what, at the moment of submission rather than at reconciliation.
The point of the third control is that attribution information is available when the message is submitted and may not be later. A deployment that reconstructs attribution after the fact depends on correlating records that were never designed to be joined, and the correlation fails precisely on the messages that matter.
What log retention does a private deployment need?
Longer than the tool holds, and stored where you control it.
Retention is what makes a private deployment defensible under scrutiny rather than merely isolated.
Three requirements apply. The retention period should exceed the longest period in which a complaint is likely, which is usually a contractual matter rather than a technical limit. The storage should be yours, so that retention is not bounded by a device’s internal capacity. And the export should be machine-readable, so that a question can be answered by querying rather than by reading screens.
The device log is an operational tool with a diagnostic horizon measured in days, and the platform’s storage is the system of record for anything that must outlive the hardware. Keeping the two distinct prevents a device replacement from becoming a record loss, which is the failure that turns an audit into an investigation.
Where the deployment carries commercial messaging, retention also serves the consent and opt-out obligations described in operational terms by M3AAWG and, for the North American market, by the CTIA. A record that shows when an opt-out arrived is what demonstrates that subsequent messages were suppressed.
What does privacy not cover?
The carrier’s own record, and anything you forward outwards.
Two qualifications keep the claim honest rather than overstated.
The first is the carrier network. A message passes through an operator’s infrastructure, and that operator holds its own delivery records outside your control. An on-premise deployment reduces the number of parties with a copy of the traffic; it does not make the traffic invisible to the network that carries it.
The second is your own forwarding decisions. A deployment that exports logs to an analytics platform, replicates them to a backup provider, or forwards delivery events to a third-party monitoring service has extended the boundary, and the extensions belong in the data-flow diagram alongside everything else. Most deployments have at least one such integration, and the honest position is to document it rather than to describe the deployment as private without qualification.
Numbering belongs in the same category. The international format that recipients and carriers use is defined by the ITU Recommendation E.164 numbering plan, and registration requirements in many markets associate a number with an identifiable entity. Privacy of infrastructure is not the same as anonymity of the sender, and treating the two as equivalent produces a compliance problem rather than a privacy one.
What should the acceptance test cover?
Reachability, attribution, and retention beyond the device.
The checks below are the ones that establish the boundary rather than the hardware.
- Management reachability. Confirm the console is unreachable from an ordinary internet connection and reachable through the intended path.
- Individual credentials. Confirm each administrator has their own account, and that a shared login is not the mechanism in use.
- Per-application attribution. Submit through two different credentials and confirm each message can be traced to the credential that sent it.
- Log export. Export the delivery record and open it in your own tooling without manual correction.
- Retention boundary. Fill the device log and confirm the export beyond that point is unaffected, because the platform rather than the device is the record.
- Data-flow verification. Confirm the documented data-flow diagram matches what the deployment actually does, including any external integration.
Item six is the one that converts the privacy claim into something auditable. Where the diagram and the deployment differ, the difference is usually an integration added after the design, and it is cheaper to find during acceptance than during a review.
Where the private deployment grows beyond one unit, the 32-port, 32-slot configuration at $1,160.00 keeps the same management model while allowing each application a larger dedicated group of channels.
Conclusion
A private deployment is defined by control of the record and the access path rather than by the location of the hardware. Keeping the message record on infrastructure you own, reaching the management interface through an authenticated path, and attributing submissions per application are the three properties that make the word meaningful. Retention should outlive the device, with the platform as the system of record and the device log as a diagnostic tool.
Two qualifications belong in any description of the deployment. The carrier holds its own record, and any integration that forwards data beyond your network extends the boundary. Documenting both, in a data-flow diagram that matches the deployment, is what allows the claim to be verified rather than asserted.
Draw the data flow before you describe the deployment as private. Send your network arrangement, access requirements and retention obligation to service@telarvo.com, or review the published configurations on the SK-SMS Gateway pages.
FAQ
Is an on-premise gateway server automatically private?
Not automatically. Privacy depends on where the message record lives, how the management interface is reached, and whether the traffic or the data is forwarded to a third party. A server in your rack that replicates logs to an external service has extended the boundary, and that integration belongs in the data-flow documentation alongside everything else.
How should the management interface be exposed?
Through an authenticated path rather than directly. A management VPN is the usual choice where you control the network edge, and an outbound-only tunnel is stronger where you do not, because it removes the need for any inbound firewall rule. Individual administrator credentials matter as much as the path, since a shared login makes every action unattributable.
Does a private gateway hide the sender from the carrier?
No. Messages pass through the carrier network, which holds its own delivery records outside your control. An on-premise deployment reduces the number of parties holding a copy of the traffic; it does not make the traffic invisible to the network that carries it. Privacy of infrastructure is also not the same as anonymity of the sender, particularly where a market requires an identifiable sending entity.
How long should message records be retained?
Longer than the period in which a complaint is likely, which is usually a contractual matter rather than a technical limit, and longer than the device can hold. The device log is a diagnostic tool with a horizon measured in days; the platform is the system of record. Exporting into your own storage is what prevents a device replacement from becoming a record loss.