Summary

  • Pureport's strongest public evidence is the customer-facing service layer: archived product pages, support documentation, legal terms and partner/customer announcements describe a self-service multicloud networking account with console access, API control, bandwidth-based billing, cloud on-ramp integration, VPN support, role permissions and support obligations.
  • The network-resource evidence is materially weaker. ARIN and PeeringDB still identify AS394351 and related Pureport/Digital Porpoise records, but RIPEstat showed no currently visible announced prefixes for AS394351 on July 9, 2026, and the main Pureport domain did not resolve during the same review. That does not erase the service history, but it prevents the ASN from carrying the current service thesis by itself.
  • The important economic question is not whether Pureport once had good cloud marketing. It is whether a small enterprise connectivity platform can keep enough control over provisioning, support, supplier access and account governance when hyperscalers, carriers, SD-WAN vendors and larger network-as-a-service platforms can all attack parts of the same budget.

The buyer starts with a routing problem, not a cloud slogan

Imagine the buyer as a small enterprise network team rather than a cloud evangelist. The company already has workloads in Amazon Web Services. A product group wants Microsoft Azure. A data project is moving into Google Cloud. A legacy system still sits in a data centre. Branch offices need access, auditors want evidence of who can change the paths, finance wants to understand why egress and circuit bills keep moving, and the network team does not want every new cloud connection to become a one-off engineering project.

That is the problem Pureport tried to turn into an account. Its archived pages describe a self-service console, a REST API, role-based accounts, child accounts, cloud connections, site VPNs, cloud-provider private connectivity, BGP peering, Cloud Grade NAT for overlapping address ranges and bandwidth that could be adjusted through the console or API. The commercial idea is straightforward: instead of buying one physical circuit, waiting on cross-connects, assigning engineers to each cloud provider and then maintaining a private routing design by hand, the customer buys a managed control surface that can create and modify private connectivity as a service.

The distinction matters because "multicloud" is often used loosely. A company can call itself multicloud because it has partnerships with AWS, Azure and Google Cloud. A customer can call itself multicloud because different teams use different public clouds. Neither statement explains who owns routing, how traffic avoids the public internet, who pays for unused bandwidth, how overlapping private address space is handled, or what happens when a route needs to be changed quickly. Pureport's public materials were strongest when they described those practical problems. The product was not simply a list of clouds. It was an attempt to make private cloud connectivity behave like a governed software account.

That is why the paid unit should be framed as recurring network control and support, not as generic cloud presence. Pureport's own materials described Cloud Connect and Site Connect as ways to privately interconnect cloud environments, sites and cloud networks. The support pages explained how a customer could create a Pureport network, add connections to AWS Direct Connect, Azure ExpressRoute or Google Cloud Interconnect, and use IPsec tunnels for remote sites. The legal terms described orders, services, charges, payment methods, support, API and console changes. The customer was not merely buying a brochure claim that "cloud is connected." The customer was paying for an account that governed who could create, modify, secure, automate and pay for those network paths.

That account layer is the most defensible way to understand Pureport. It also gives the business a natural limit. The more value lies in governance, automation and account management, the more Pureport has to prove that its control surface remains easier, safer and more economical than the native controls of hyperscalers, carriers, SD-WAN vendors and network-as-a-service rivals.

The service account is the economic unit

Pureport's archived legal and support materials make the service-account framing explicit. Its master service agreement defined services as features, functionality and other services offered as part of Pureport's product offering. It described orders, policies, an SLA, a Pureport Console, recurring charges, usage-based metering, overages, plan changes, refunds, rate modifications, suspension, account security and API access. The terms said users authorized to make modifications or add services through the console or API could incur additional fees. The same agreement placed billing and contact information in the Pureport Console and allowed changes to orders during the term through the console or API.

That language is important because it shows where the money would sit. Pureport did not need to own every underlying fibre path to charge a customer for governed network control. It needed to make the account valuable enough that a customer would rather manage multicloud connectivity through Pureport than stitch together circuits, cloud on-ramps, VPNs and BGP sessions directly. The product evidence supports that thesis. The archived Multicloud Fabric page described connections from 50 Mbps to 1 Gbps, self-service management, bandwidth scaling, API access, a private backbone, full-mesh routing, BGP peering, Cloud Grade NAT and hourly allocated-bandwidth pricing. Later archived pages and announcements described higher bandwidth ranges and no long-term contracts in some offers.

The governing object in the buyer's life is therefore not a cable. It is an account containing networks, connections, roles, API keys, billing settings and permissions. Pureport's support documentation described accounts as company or billing units, child accounts as a way to segregate business units, teams or environments, and roles as permission sets for resources such as networks, connections, roles, members, accounts and billing. The API documentation described API keys tied to roles and account paths for creating networks and adding connections. This is enterprise governance language. It tells a buyer that network changes can be assigned, automated and controlled, not just requested by email from a carrier.

That makes Pureport resemble a cloud management surface as much as a network operator. A traditional private line sale might be evaluated by installation interval, port cost, local loop availability and service-level credits. A Pureport sale would also be evaluated by how much work is removed from the network team: whether a DevOps team can create test connectivity without opening a telecom project, whether a production change can be limited to a role, whether a finance or platform team can see usage, whether a partner or business unit can be separated through account hierarchy, and whether a recurring bandwidth bill can be scaled down when a project ends.

The product claim is attractive because it converts lumpy network work into software administration. The risk is that buyers will only keep paying if the administration layer controls enough of the underlying complexity. If cloud providers improve their own private connectivity procedures, if a carrier bundles the same governance into a managed WAN contract, or if a network-as-a-service platform offers broader reach, Pureport's account layer has to keep a visible advantage.

Cloud dependency is the real customer dependency

The public service evidence is directly customer-facing. Pureport published pages for a multicloud networking platform, a console, an API, Cloud Connect, Site Connect, cloud-specific connections and support procedures. It described private access to AWS, Azure, Google Cloud, Oracle Cloud and IBM Cloud, and support documentation walked through practical combinations such as connecting AWS VPCs to Azure virtual networks through Direct Connect and ExpressRoute.

The dependency is not that customers depended on Pureport for compute or storage. The dependency is that customer applications, data flows and onboarding processes depended on private access to cloud environments. Pureport sat in the control path between customer sites, customer cloud accounts, cloud-provider private connectivity products and network policies. In that position, it was selling reduced friction: fewer long provisioning cycles, less specialized BGP labour, fewer carrier contracts, and a more manageable way to connect environments that were not built by the same provider.

The MediPortal announcement is a useful example, with caveats because it was a company-originated press release. MediPortal, a SaaS company, was described as needing private connectivity between medical sites, patients, payors and its AWS environment. The announcement said Pureport helped orchestrate private connectivity between hospitals, physician sites and AWS through Pureport's console, with IPsec from remote sites to regional gateways and AWS Direct Connect onward to the cloud. It also said overlapping IP addresses had become an onboarding problem. The facts should not be inflated into proof of durable revenue, healthcare compliance outcomes or ongoing service quality. But they do show the kind of buyer pain Pureport wanted to monetize: a SaaS company could not make every customer connection into a custom telecom project.

The same logic appears in Pureport's archived support pages. A Pureport network could include an AWS VPC, an Azure vNet and a physical location via IPsec, with those environments communicating directly if security settings allowed it. The locations-and-cloud-mappings support page listed how Pureport locations mapped to cloud regions. The API page showed a programmatic sequence from account authentication to network creation and an AWS Direct Connect connection. Those details matter more than brand claims because they reveal the customer's operating dependency: business projects become dependent on a controlled path among cloud environments, not just on the cloud providers themselves.

This is also where switching cost starts. A buyer that has only tested a Pureport demo can walk away. A buyer that has created accounts, child accounts, roles, API keys, Pureport networks, NAT policies, BGP sessions, VPN tunnels and cloud on-ramp links has created operating memory. The switching cost is not just the monthly bill. It is the rework needed to rebuild paths, recreate policies, retest traffic flows, revise automation, retrain staff, and reset the support approach for the same application estate.

The cost base is hidden inside the promise of speed

Pureport's sales proposition used speed as a weapon. It contrasted creating private connectivity in minutes with the weeks or months often associated with physical circuits, carrier cloud on-ramps and equipment-heavy deployments. That promise is economically powerful, but it also points to the cost base.

To make "minutes" credible, Pureport needed pre-positioned relationships, capacity and automation. The archived locations page listed five key United States regions: Northern Virginia, Chicago, Dallas, San Jose and Seattle, each tied to secure Equinix facilities and cloud-region access. PeeringDB later listed five facility records for AS394351 in Ashburn, San Jose, Chicago, Seattle and Dallas. The support documentation described redundant paths, redundant equipment, high-capacity switching, backbone connections and private cloud-provider connections. The PacketFabric partnership announcement described Pureport customers accessing Pureport from PacketFabric points of presence and riding PacketFabric's backbone to Pureport's core cloud gateways.

The commercial shape is clear. Pureport could sell rapid provisioning because it had already done some of the slow provisioning work in advance or could rely on partners who had. That creates operating leverage if demand fills the platform. The same fixed preparation can serve many customer networks. But it can also create exposure if demand is thin, if partner pricing changes, if cloud on-ramp economics change, if facility commitments become stale, or if larger platforms make the same reach cheaper.

The buyer sees an adjustable bandwidth control. The operator sees a portfolio of infrastructure, cloud-provider interfaces, transit or backbone dependencies, software orchestration, support staff and billing systems. The buyer wants to pay only for the bandwidth required at that moment. The operator has to forecast how much capacity to maintain before demand arrives. That is the basic tension in on-demand network services. The customer wants variable spending; the provider has to carry enough readiness to make the variable service feel immediate.

Pureport's archived legal terms reinforce that the commercial structure was not pure usage with no obligations. The agreement described minimum terms, automatic renewal, recurring payment authorization, nonrefundable payments, rate changes after an initial term, service changes through the console or API, and responsibility for taxes. Product pages and announcements also used flexible or no-contract language in some contexts. These are not necessarily contradictory; service terms can vary by order and product. The important point is that buyers should not read "on demand" as "no governance." The service account still needs contract terms, billing rules, roles, controls and termination paths.

For an enterprise network buyer, the economic test is whether Pureport lowers the total cost of getting reliable private paths among environments. That total cost includes cloud egress, cross-connects, port fees, engineering hours, change windows, support delay, security review, route mistakes and project opportunity cost. If Pureport only replaces one line item, it competes on price. If it reduces the whole coordination burden, it can defend a higher-value account.

Supplier and upstream dependence are central, not incidental

Pureport's value proposition depended on other companies' infrastructure. That is not a criticism; it is how much of the cloud-connectivity market works. The question is how much control Pureport retained while depending on cloud providers, colocation facilities, backbone partners and customer equipment.

On the hyperscale side, Pureport's pages referred to native private connectivity products such as AWS Direct Connect, Azure ExpressRoute and Google Cloud Interconnect. Those products set technical and commercial boundaries. They determine peering designs, cloud-region mappings, accepted ASNs, gateway behaviour, port locations, data-transfer economics and change procedures. Pureport could simplify and orchestrate access, but it could not unilaterally rewrite AWS, Microsoft or Google networking rules. The support pages reflected this clearly: customers still needed cloud accounts, virtual networks, VPCs, ExpressRoute circuits, Direct Connect gateways, security rules and route table propagation.

On the facility side, Pureport's 2019 footprint leaned on Equinix locations. PeeringDB's facility records show Pureport listed in five Equinix facilities or facility groups. That gave the platform a recognizable, carrier-neutral data-centre backbone for the United States footprint. It also meant that the service's geography was bounded. The archived locations page said Pureport planned additional domestic and global regions in 2019, but the evidence reviewed here does not prove that a broader Pureport-owned footprint became durable or remains active.

On the partner side, the PacketFabric announcement is the most explicit. It said enterprises could access Pureport from more than 150 PacketFabric points of presence across the United States, Europe and Asia-Pacific, then ride the PacketFabric backbone to Pureport core cloud gateways. That is useful distribution. It is also dependence. A Pureport customer might experience the combined result as one service, but the reach depends on another network-as-a-service provider's footprint and commercial terms.

On the customer-premises side, Pureport emphasized not requiring additional hardware. The Site Connect and support pages said customers could use existing on-premises equipment, including IPsec tunnels, route-based or policy-based tunnels and a range of encryption options. That reduces friction, but it shifts part of reliability back to the customer's internet access, firewall configuration, BGP support and security rules. A platform can automate a lot. It cannot make every customer edge device modern or every internal address plan clean.

This supplier dependence is why Pureport should not be evaluated like a simple SaaS vendor or a simple carrier. It is a control layer over a stack of other controls. Its value rises when those controls are hard to coordinate. Its risk rises when one supplier or substitute makes the coordination problem smaller.

Governance is a feature because network authority is dangerous

Pureport's account and role design is more than administrative decoration. In a multicloud network, the ability to create a connection, change bandwidth, alter a route, generate an API key or modify a child account can change who can reach production systems. Governance is part of the product.

The support article on accounts, members and roles described accounts as company or billing units, child accounts as a way to segregate teams or business units, and roles as permission sets for networks, connections, members, accounts and billing. API keys could also be assigned roles. The API support page recommended limiting an API key to the roles required by a script or application. The console page described permission-based user roles, billing information and invoices. The master agreement said customers were responsible for account activity and that authorized users making modifications or adding services could incur fees.

That is why the headline says Pureport makes multicloud connectivity a governed service account. The paid value is not just that traffic moves. It is that network authority can be assigned to users, roles, API keys and accounts. For an enterprise, that can reduce the risk of informal routing changes and uncontrolled telecom spending. It can also create a new concentration of authority. If the Pureport account is misconfigured, if API keys are over-permissioned, if child accounts inherit too much billing or network control, or if internal offboarding fails, the network governance layer can become a control risk.

Pureport's acceptable use policy and master agreement show how the provider tried to bound its own exposure. The AUP prohibited unlawful, abusive, deceptive, harmful and rights-violating use, and allowed suspension or termination in response to complaints or unresolved violations. The master agreement allowed suspension for security risk, liability risk, fraud, nonpayment and similar issues. Those provisions are standard, but in network connectivity they have practical force. A suspended account is not just a login problem. It can affect application paths.

For buyers, the lesson is to treat the account as infrastructure. Procurement should not approve a service merely because it makes cloud networking easy. Security, finance and operations should ask who can create connections, who can alter bandwidth, which environments are separated into child accounts, how API keys are rotated, how billing authority is controlled, how incidents are escalated, and what termination or suspension would do to production traffic.

Support obligations turn automation into an operational promise

Pureport's public materials repeatedly sold simplicity: create private connectivity in minutes, connect clouds without deep expertise, avoid long carrier timelines, automate BGP details, use existing equipment. But any service that reduces required expertise for the customer increases responsibility for the provider. If the customer no longer has a dedicated BGP routing specialist on every project, the provider's support, documentation and automation have to absorb more edge cases.

The support documentation was therefore central evidence. It included basic concepts, account roles, API usage, cloud mappings, AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect, VPN routing, BGP ASN guidance, security groups and latency testing. That body of documentation shows an implementation-support surface rather than a pure marketing site. It also reveals where the service can fail or become labour-intensive: route propagation, address overlap, cloud-region mapping, edge device compatibility, static versus BGP routing, security rules, public versus private peering and old devices that do not support 4-byte ASNs.

The ASN support article is especially telling. It said Pureport used public ASN 394351 for all BGP peering and that customers could not change it. It listed cloud-provider ASNs and reserved ranges to avoid. It warned that older firewalls and routers may not support 4-byte ASNs and recommended static routing in those cases. This is exactly the sort of practical support burden that makes a connectivity service valuable and hard. A polished console can start the sequence, but the customer's firewall, cloud account and address plan still determine whether the sequence completes cleanly.

Support also intersects with customer economics. The MediPortal announcement claimed a first customer connection could be provisioned within ten minutes and onboarded in less than three hours. That is useful, but the more important point is not the exact timing claim. It is that customer onboarding delay was the business pain. If every new medical site required bespoke carrier provisioning, MediPortal's SaaS growth would be constrained by network integration labour. Pureport's promise was to turn that labour into a repeatable service path.

The same support burden is a competitive risk. Larger carriers have support teams and existing enterprise contracts. Hyperscalers have increasingly mature documentation and direct connection ecosystems. SD-WAN and SASE vendors can wrap cloud connectivity into broader security, policy and application-performance offers. Network-as-a-service platforms can expose programmable connectivity across larger footprints. Pureport's support promise had to be better than a buyer's next-best integration path, not merely better than a manually ordered circuit.

The public network-resource record is useful but downgraded

Public network-resource records make Pureport more tangible, but they do not prove the current service thesis. ARIN RDAP lists AS394351 with the name DIGITAL PORPOISE and active status. The registrant entity in the ARIN record is Digital Porpoise, LLC. The same ARIN entity record lists associated IPv4 and IPv6 allocations, including 45.40.32.0/20, 45.56.204.0/22 and 2606:cf80::/32. PeeringDB lists a Pureport network entry for AS394351, with website https://pureport.com, network type NSP, zero listed IX connections, five facility records, not-disclosed traffic and scope, and status ok. PeeringDB's facility records place the network in Equinix Ashburn, San Jose, Chicago, Seattle and Dallas facilities.

That is more than a stale company name in a database. It shows that Pureport had a recognized public network identity and facility footprint consistent with its 2019 location pages. It also explains why the company matters to readers studying cloud-connectivity accountability: AS394351 is a public clue tied to a named organization and a multicloud connectivity service.

But the current routing evidence is weak. RIPEstat's AS overview on July 9, 2026 described AS394351 as DIGITAL PORPOISE - Digital Porpoise, LLC and reported it as not announced at the query time. RIPEstat's announced-prefixes and BGP-state data showed no visible current prefixes or routes. Its routing-status data showed zero visible IPv4 or IPv6 announced space and zero observed neighbours, with the last seen route for AS394351 reported in 2021. Its routing-consistency data showed IRR records for prefixes but marked them as not in BGP. That means the ASN and address records cannot be used as proof of live traffic, current customers or active interconnection.

The record also contains signs of changed operational context. ARIN entity and network records reviewed in 2026 included operational contacts and a reassigned 45.40.32.0/31 record using Digital Realty-related contact names or domains. That does not prove an acquisition, a service shutdown or a particular ownership change. It does show that public number-resource records now have operational details that do not read like a simple standalone Pureport contact surface. The prudent conclusion is uncertainty.

This is why network-resource evidence is useful but limited. It identifies the accountable ASN and facility footprint. It is not strong enough to carry a current connectivity-service thesis without product, support and customer-facing evidence. If a future review finds active AS394351 announcements, current prefixes, visible peers, updated PeeringDB contacts, a restored Pureport website and current customer terms, the network-resource grade would improve. As of this review, it is a historical and registry-supported clue, not live proof of service quality.

The main-site signal is a warning, not a verdict

The current web status adds another caution. On July 9, 2026, pureport.com and www.pureport.com did not resolve from the public retrieval environment used for this review. The old console and API hostnames timed out during DNS resolution checks, while help.pureport.com still reached a Freshdesk service returning a 404 at the root. LinkedIn's public company page still described Pureport as a Raleigh, North Carolina IT services and consulting company founded in 2018, with 11-50 employees and a cloud-networking description, but LinkedIn is a profile surface rather than proof of active commercial operations.

A non-resolving main domain is not enough to conclude that a private company is dead. Domains can move, DNS can be misconfigured, services can be private, brands can be replatformed, and customer portals can exist behind other hostnames. But for a cloud connectivity provider, the loss or disappearance of the main public site is a meaningful market signal. It reduces buyer confidence, makes documentation harder to find, interrupts discovery, and suggests that the public face of the service is not being maintained in the way a growing self-service platform normally would be.

The right reading is conservative. Pureport had strong archived service evidence. It had named partners and at least one customer announcement. It had support documentation deep enough to show practical implementation. It had AS394351 and PeeringDB facility records. But the current public surface does not support a confident claim of a thriving live network service. This piece therefore analyzes Pureport as a governed multicloud connectivity service account with a documented product history and a weak current public-routing footprint.

That distinction protects readers from two opposite mistakes. The first mistake would be to treat a dead or non-resolving domain as if it invalidates every historical service claim. It does not. The second mistake would be to treat archived product claims and an active ARIN status as if they prove current customer success. They do not. The available evidence supports the business structure and operating surface, not the present quality or scale of execution.

Competition compresses the middle layer

Pureport's competitive problem is that many different substitutes can attack the same enterprise need from different directions.

The first substitute is direct hyperscale networking. AWS Direct Connect, Azure ExpressRoute and Google Cloud Interconnect are not just supplier inputs. They are also alternatives. An enterprise with strong network engineering staff can buy directly into the cloud-provider ecosystem, manage its own circuits, use cloud-native routing constructs and avoid paying an additional control-layer provider. This is especially attractive for large buyers that already have telecom procurement, colocation footprints and cloud centre-of-excellence teams. Pureport's answer was speed, automation, NAT handling, full-mesh routing and reduced expertise. That answer is strongest for buyers that cannot or do not want to build the internal skill set.

The second substitute is the carrier-managed WAN. A carrier can sell cloud connectivity as part of a broader MPLS, internet, Ethernet, voice or SD-WAN contract. The carrier may not be as fast or elegant as a self-service software platform, but it can package access, support, billing and service credits into an existing enterprise relationship. For conservative buyers, one incumbent provider can be easier to manage than a new specialist platform. Pureport's answer was freedom from long carrier timelines, no additional hardware in some procedures and a more cloud-like management approach.

The third substitute is SD-WAN or SASE. These vendors can make branch-to-cloud and cloud-to-cloud paths part of a broader security, policy and application-performance system. If the buyer's main problem is application access for users and branches, a security-led networking platform may feel more strategic than a private cloud-connectivity fabric. Pureport's answer was deeper native private connectivity to cloud providers and full-mesh private routing, rather than overlay-only application access.

The fourth substitute is another network-as-a-service platform or private circuit broker. PacketFabric itself, Megaport, Equinix Fabric and similar services can offer programmable private connectivity across broad footprints. Some have stronger brand recognition, larger reach or deeper ecosystem integration. Pureport's answer was its distributed multicloud router, Cloud Grade NAT, console/API approach and cloud-to-site mesh. The question is whether that differentiation was large enough to overcome the distribution and capital advantages of bigger platforms.

The fifth substitute is internal network engineering. For some buyers, the lowest-risk path is to hire or retain the engineers who know the company's address plan, compliance requirements and cloud estate. Internal work may be slower at first but can be more controllable over time. Pureport's promise was to let IT generalists, DevOps teams or network specialists build private connectivity without a dedicated BGP specialist. That promise appeals when internal expertise is scarce. It weakens if the customer already has that expertise and wants to avoid another dependency.

These substitutes show why Pureport's paid unit needed governance and support, not just connectivity. Connectivity alone becomes a commodity comparison. Governed connectivity can defend more value if it reduces mistakes, speeds onboarding, documents authority and lowers coordination cost.

Regulation and geopolitics appear through control, not nationality

Pureport is not a telecom regulator, a national operator or a sovereign cloud. The regulatory and geopolitical issues are more practical: who can reach regulated workloads, which cloud regions are used, how private paths cross jurisdictions, who can suspend service, how acceptable-use obligations are enforced, and whether a customer's compliance team can understand the dependency chain.

The support documentation shows how region selection matters. The locations-and-cloud-mappings page mapped Pureport locations to AWS, Azure and Google Cloud regions. It noted Azure peering locations and cloud regions. A buyer connecting healthcare, financial or public-sector workloads through a private connectivity service would need to know not just that a path is private, but where it enters cloud-provider networks, what regions are reachable, what logs and records exist, and which parties can see or affect traffic.

The AUP and master agreement also show that service control is conditional. Pureport could suspend service for abuse, security risk, legal risk, fraud, nonpayment or violations. That is normal for infrastructure services. It still matters because the service sits in a path that customer applications may depend on. Buyers in regulated industries should treat suspension rights, support responsibilities, data responsibilities, account security and acceptable-use obligations as operational risk, not boilerplate.

Geopolitics also enters through suppliers. If a service depends on US facilities, US cloud on-ramps, US-based legal terms and partner backbones, it may be less suitable for buyers requiring local-country operational control or explicit data-residency claims. Pureport's archived materials emphasized United States regions and cloud provider access. They did not prove a sovereign, local-residency or cross-border compliance product. That restraint matters. Multicloud connectivity can sound global by default because cloud brands are global. But global logos do not prove cross-border route control, international resilience or jurisdictional data assurances. The evidence here supports a North American cloud-service dependency story with US facilities and cloud-region mapping. It does not support a stronger geopolitical thesis.

What the unofficial market signals suggest

Private-company market signals should be read as weak evidence unless they are tied to hard records. In Pureport's case, the public signals are mixed. LinkedIn still presents a company profile with a Raleigh headquarters, 2018 founding date, cloud networking description, specialties in SD-WAN, software-defined networking, network function virtualization, AWS Direct Connect, Microsoft Azure ExpressRoute and Google Cloud Interconnect, and a small company-size band. Archived pages showed hiring and sales roles in 2020. Archived press releases showed partnerships with AVANT, PacketFabric and Element Critical and a customer announcement with MediPortal. Those signals show market activity around 2019 and 2020.

The negative signals are also public. The current main domain did not resolve during review. The routing record lacks visible current announcements. PeeringDB still shows a 2019-created entry updated in 2022, with no IX connections, not-disclosed traffic and no current visible exchange presence. The official support subdomain reaches a hosted helpdesk service but not a current public documentation home at the root. These are not fatal facts individually. Together, they make scale and current operating strength unproven.

The financing story should also be handled cautiously. Private-company databases and secondary market notes may carry funding estimates, but accessible public evidence reviewed here was not sufficient to make fundraising a central article fact. The stronger economic story does not need a precise venture number. Pureport's product either solved a real coordination problem for enterprise cloud networking or it did not. Its competitive risk would remain even with more funding: the middle layer between hyperscale cloud connectivity, carrier WAN, colocation fabrics and SD-WAN is valuable but crowded.

The best market interpretation is that Pureport identified a real buyer pain before the market fully settled on how multicloud private connectivity should be packaged. It tried to package that pain as a self-service account. Whether that became a durable business at scale is not proven by the public record now available.

What facts would change the judgement

Several facts would materially improve the assessment. The first would be a restored current official website with current product pages, legal terms, support contacts and customer documentation. That would reduce the current-status caveat and let readers distinguish a live platform from an archived product history.

The second would be active routing evidence for AS394351 or a successor ASN clearly tied to Pureport. Visible announced prefixes, observed neighbours, updated PeeringDB contacts, current facility records, route objects that align with live BGP, RPKI coverage and cloud/interconnect peers would upgrade network-resource evidence. The current ARIN and PeeringDB records are useful, but RIPEstat's lack of visible routes is a real limit.

The third would be current customer or partner proof. Fresh customer case studies, partner marketplace listings, cloud-provider partner pages, current support articles, public status pages, or procurement documents would help separate historical marketing from active service delivery. The archived MediPortal, PacketFabric, AVANT and Element Critical announcements support the service thesis historically, but not current scale.

The fourth would be clearer legal and corporate continuity. Pureport's archived master agreement identified Pureport, Inc. as the contracting entity. ARIN identifies Digital Porpoise, LLC as the registrant behind AS394351. Public records that explain the relationship among Pureport, Digital Porpoise and any later operational contacts would reduce uncertainty around the responsible organization.

The fifth would be pricing and unit economics. Pureport's pages described hourly or monthly allocated-bandwidth charging, month-to-month and term commitments in different contexts, and recurring charges in the legal terms. More current pricing would show whether the platform competed as a low-cost circuit substitute, a premium governance layer, a partner-distributed service, or a narrow support-and-automation layer over other providers.

Absent those facts, the cautious judgement is still meaningful. Pureport has enough public product and support evidence to be read as a cloud-connectivity service account. It should not be described as a proven active network operator on the strength of AS394351 alone.

Conclusion: control is the product, uncertainty is the caveat

Pureport is worth studying because it illustrates a shift in enterprise networking. As companies spread workloads across cloud providers and keep some systems in data centres or branch offices, the hard problem is not only obtaining a private path. It is governing a growing set of paths, roles, routing settings, accounts, APIs, NAT policies, cloud-region mappings, bandwidth changes and support obligations. Pureport's public materials framed that problem clearly and sold an account-based answer.

The strongest evidence supports that account-based answer. The company described a console, API, multicloud fabric, cloud and site connection types, role-based access, child accounts, BGP peering, IPsec tunnels, Cloud Grade NAT, private cloud-provider connectivity, bandwidth scaling and support documentation. Its legal terms described recurring service orders and account responsibility. Partner and customer announcements showed how the service was meant to fit into enterprise and SaaS onboarding procedures.

The caveat is equally important. The public network-resource record no longer supports a strong live-footprint claim. AS394351 exists in ARIN and PeeringDB records, but RIPEstat showed no current visible announcements on July 9, 2026. The main Pureport domain did not resolve during review. The support subdomain was reachable only as a hosted helpdesk root returning 404. These facts do not invalidate the historical service. They do mean the current operating state is not proven.

That is the economic lesson. A platform like Pureport can create value by making multicloud connectivity feel like governed software instead of bespoke telecom work. But that value is durable only if the control layer remains live, trusted, supported and better than the substitutes surrounding it. The buyer pays for governed connectivity. The analyst should ask whether the governance surface is still visible, whether the network evidence is current, and whether the service account remains the easiest way to manage the cloud paths on which customer operations depend.