During a production-readiness review for a Tier-2 MNO, Southeast Asia, ~18M subscribers, the incoming MVNO’s roaming test traffic exposed a familiar gap: every team assumed someone else owned the SS7 controls. The issue was not whether a MAP firewall existed, but whether its policy model reflected the MVNO’s IMSI ranges, MNP routing and lawful-access obligations. MAP firewall policy is therefore an onboarding deliverable, not a background network function.
The onboarding failure appears at the signaling boundary
The failure surfaced when a roaming test generated MAP activity against a newly assigned IMSI range. The core-network team confirmed that the traffic reached the expected boundary. It could not confirm whether the transaction set should pass. The security team had not approved a range-specific screening posture, while the launch team had treated successful connectivity as evidence that signaling controls were ready. The distinction held the production decision open.
The ownership structure looked conventional. The MNO retained the SS7 interconnect, firewall estate and external carrier relationships. The MVNE controlled subscriber lifecycle data and the provisioning path. The MVNO expected its roaming profile to operate as an extension of the host network. Yet none of the governing schedules translated those boundaries into a signed policy model. There was no agreed authority for approving a new source network, changing a rule or deciding whether a failed transaction represented abuse, misconfiguration or an incomplete roaming profile.
A default-deny posture can limit reconnaissance, location disclosure and unauthorized subscriber interrogation. It can also interrupt valid transactions when the tenant’s identifiers and counterparties are absent from the rule base. Legitimate SRI-SM, ATI, PSI and routing-related operations do not become safe merely because they originate from a known carrier. Equally, they should not be blocked solely because a recently onboarded tenant has not yet been represented in a host-wide policy model.
The operational question is not which party pays for the firewall licence. It is who can request a change, who validates its commercial and regulatory basis, who tests the resulting behavior and who accepts the incident obligation after production. Approval authority without tenant data is weak control. Tenant knowledge without access to firewall telemetry is weak accountability.
A Tier-2 head of wholesale recently observed: “The launch plan had a roaming workstream and a security workstream. Neither one contained the other.”
The first production gate should therefore require an agreed signaling transaction inventory. At minimum, it should identify source networks, destination GTs, IMSI and MSISDN ranges, expected MAP operations, roaming conditions and named escalation contacts. The inventory should also identify which party can produce evidence that a rule was approved and tested. Without that record, an exception raised during launch becomes a negotiation conducted against the production clock.
Host ownership does not remove MVNE accountability
The MNO should retain control of interconnect exposure and security enforcement. It normally remains accountable for SS7 interconnect governance, firewall-rule approval, threat intelligence, monitoring thresholds and the response to signaling abuse affecting the shared HLR, AuC or broader subscriber estate. That authority is necessary because one tenant’s exception can alter risk across other tenants and the host network itself.
The MVNE’s responsibility is different but no less operational. It must maintain accurate tenant identifiers, including IMSI blocks, MSISDN ranges, HLR or HSS routing context, activation states and roaming entitlements. It must also preserve the data lineage between BSS/OSS records and core provisioning. If an alert concerns an IMSI that appears inactive in one system and provisioned in another, firewall ownership alone cannot resolve the event.
This becomes material at portfolio scale. An MVNE servicing 12+ tenants in EMEA found that host-level controls were consistent, but tenant records reached the security process through different operational channels. Some changes arrived through formal change control, others through roaming tickets, and others through launch spreadsheets. The technical policy was centralized; the evidence feeding it was not. Standardizing the intake and validation path reduced ambiguity without transferring firewall authority away from the host.
The MVNO should own the commercial intent behind the service design. That includes target roaming markets, number-range use, customer-support routes and any differentiated behavior likely to change signaling patterns. It should not receive unrestricted authority to alter host security policy. Commercial urgency is relevant to prioritization, but it is not a substitute for an approved source, transaction purpose or regulatory basis.
Responsibility needs to follow the control plane. A party that cannot observe a firewall event cannot be the sole incident owner. A party that cannot establish whether an IMSI is legitimately active cannot close an investigation without MVNE input. The operating model must therefore join decision rights to evidence obligations: the MNO controls exposure, the MVNE validates subscriber state, and the MVNO confirms whether the observed behavior matches the product’s commercial intent.
Change windows must also cover more than subscriber activation and OCS configuration. They should include screening-rule deployment, rollback conditions, roaming test cases, alert tuning and confirmation that lawful-access interfaces retain required reachability. For multi-IMSI or multi-host propositions, each identity domain needs a separate responsibility map. A policy valid for one host MNC/MCC pair may be unsafe or non-compliant when traffic is steered through another host or roaming partner.
Roaming, MNP and lawful access turn policy into a production control
The difficult cases begin where subscriber identity, routing authority and legal jurisdiction diverge. Roaming introduces counterparties that the domestic launch team may not otherwise assess. Firewall policy must distinguish expected roaming operations from anomalous requests while retaining enough telemetry to investigate failed authentication, location and SMS-routing events. A static allowlist may support an initial test, but it does not provide an operating model for new roaming routes, altered hubs or emergency changes outside business hours.
MNP adds a separate source of ambiguity. Porting changes the relationship between MSISDN allocation and serving-network routing. Screening logic and troubleshooting procedures must not treat the number range alone as proof of current subscriber status. This is particularly important where SRI-SM, routing queries or legacy lookup flows remain in use. A transaction can be syntactically valid and still rely on stale assumptions about which network serves the subscriber.
The division of work should be explicit. The MNO defines the permitted signaling surface, approval threshold and escalation authority. The MVNE reconciles active subscriber records against HLR or HSS state and MNP data. The MVNO provides prompt notice of product changes that alter expected international usage, support patterns or identity selection. None of these duties can be inferred reliably from the party that owns the customer brand, the host licence or the provisioning platform.
A Greenfield MVNO, post-2023, multi-IMSI stack encountered this issue when separate identity domains produced different expected routes for the same service proposition. Successful tests against the primary identity did not validate the secondary host path. The useful remediation was not a broader exception. It was a domain-by-domain test plan tied to specific source networks, expected MAP operations, log locations and incident contacts.
Lawful-access dependencies require the same precision. The evidence chain should cover time synchronization, controlled or immutable access to logs, retention ownership, export procedure and named authority for responding to a valid request. The parties should know which records establish the source GT, queried identity, transaction type, screening outcome and subsequent rule change. These are not details to discover after a regulator or competent authority has imposed a response deadline.
A practical launch rehearsal uses negative tests as well as success tests. It should include blocked unauthorized MAP requests, queries for inactive IMSIs, ported-number edge cases, roaming traffic from an unplanned source and escalation outside business hours. The objective is not merely to demonstrate that expected traffic passes. It is to prove that prohibited traffic is rejected, evidence remains available and the correct party can make a controlled decision when the event does not match the script.
The commercial consequence is measurable even when the security event never becomes public. Unclear responsibility extends launch assurance, increases false-positive investigation costs and can leave the MNO carrying regulatory exposure without the tenant data needed to resolve it. It also creates dispute risk: each delayed exception becomes a question of whether the host control, MVNE record or MVNO requirement was incomplete. A concise responsibility schedule reduces delay by fixing decision rights before provisioning begins.
As MVNO portfolios become more international and identity models more complex, signaling security will move from inherited host-network plumbing to an explicit onboarding control. MNOs and MVNEs that assign decision rights, evidence obligations and test ownership before provisioning begins will face fewer launch delays and cleaner incident accountability. The firewall remains a host control, but its policy can only be operated safely when every party supplies the data, authority and response discipline that the shared signaling boundary requires.