Bulk internet agreement vs managed WiFi: which model fits your building

Welcome to Purple's technical briefing on bulk internet agreements versus managed WiFi. If you own or operate a building, connectivity is no longer just a line item on a utility schedule. It affects move-in readiness, support demand, building access, security boundaries, and your ability to change providers later. The first point is straightforward. There are three common ways to provide residential or venue connectivity. You can let each resident buy their own retail broadband. You can buy a building-wide connection from one ISP, usually called bulk internet in the United States. Or you can run managed WiFi as a building service, where the building or its appointed operator manages the access network and the resident experience. These are not interchangeable procurement labels. They assign responsibility differently. Under resident-paid retail broadband, every resident becomes a separate buyer. They choose, order, install, pay for, and cancel their own service. That can preserve individual choice where several providers can reach the property. But it also means your move-in team inherits a different failure pattern. A resident who arrives on Friday with no active service will be calling a retail provider, not your network team. You may have little visibility of the in-building equipment, and little ability to standardise coverage or isolate faults. A bulk internet agreement changes the commercial model. The building owner or operator contracts with a single ISP to supply service for the property. The cost is commonly recovered through rent, a service charge, or a separate resident fee. In US multi-tenant environments, the FCC says bulk billing itself is not currently prohibited. It also says service providers may not use a bulk billing agreement that gives them exclusive rights to access and serve the building. That distinction matters. A building-wide contract can be lawful while a contract that blocks all competing provider access can create a problem. In the UK, you are more likely to hear building-wide broadband, landlord-provided internet, or a block broadband agreement. The procurement principle is the same. You need to separate the upstream connection from the inside-building network. The government requires new homes in England to have gigabit-capable infrastructure and, where available within the defined cost cap, a gigabit-capable connection. For existing blocks, the Telecommunications Infrastructure Leasehold Property Act created a route for operators to seek access when a landlord is repeatedly unresponsive. Neither point tells you which commercial model to buy. Both make access, ducts, risers, and termination points part of the decision. Managed WiFi takes a different position. It treats in-building connectivity as an operating service rather than a retail product attached to each flat. You decide who holds the upstream circuit contract, who owns or leases access points and switches, who provides monitoring, and how identities receive access. A managed service can run on the equipment you already own, but only if the design and contract say so. Purple is hardware-agnostic and integrates with Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. That gives you a route to keep the network asset separate from the ISP relationship. Now move from labels to the operating questions that matter. First, who owns the asset? In resident-paid broadband, the retail provider normally controls the service endpoint and may provide a router within each unit. Your property is still responsible for shared paths, access permissions, and any landlord-owned wiring. In bulk internet, the ISP may own the circuit and some of the active equipment. You must identify what happens to that equipment at contract end. In managed WiFi, the building can own the access layer or lease it under a service agreement. The better model is not the one with the lowest headline connection price. It is the one that makes ownership, replacement, and handover explicit. Second, what happens at move-in? With retail broadband, the resident places an order and waits for the provider to activate service. With bulk internet, a connection may already exist, but the resident still needs the supplier's onboarding and support process. With managed WiFi, the design can make access available from the first day, then apply an identity policy to the resident. That policy might use a WiFi Pass, iPSK, or a private network bubble, depending on your design. Do not buy the term without testing the handover. Third, what happens when a resident leaves? Retail broadband ends or transfers under the resident's account. With bulk internet, billing and access removal depend on the service agreement. With managed WiFi, your joiners, movers, leavers process should remove access at the end of occupancy and retain only the records your data policy requires. This is where centrally managed Identity-Based Networks are useful. They tie network access to a role or identity, rather than leaving a static shared credential behind. The next question is cost. Is bulk internet cheaper than managed WiFi? Often, it looks cheaper at the circuit level because one building-wide commitment can replace many retail tariffs. But that comparison is incomplete. Include the access layer, survey, installation, power, monitoring, support, replacement cycles, resident communications, service credits, data handling, and exit costs. Compare total operating cost over the contract term, not the first monthly price. A low wholesale rate is not a low-cost service if your team then handles every coverage fault, apartment move, and equipment swap. A practical tender asks bidders to price the same scope. It should cover the upstream circuit, in-building cabling, access points, switches, authentication, management, fault handling, resident support, data protection, and end-of-term handover. Ask for one-time costs, recurring charges, implementation milestones, response times, service credits, and the ownership of every component. A bidder that cannot identify the demarcation point has not priced the same service. Then test security. Resident convenience is not a reason to create a flat network. IEEE 802.1X is the standard for port-based network access control. It uses a controlled port for secure access-controlled communication and an uncontrolled port for authentication and key management. For staff devices, payment systems, building operations, and resident access, use segmentation that reflects risk. The PCI Security Standards Council publishes separate guidance on scoping and segmentation for modern architectures. That is relevant wherever a hotel, retailer, stadium, or conference venue has cardholder data systems. Put resident and guest traffic outside the payment environment, define permitted paths, and test the boundaries after changes. For staff networks, enterprise authentication gives you a cleaner answer than one shared password. Use IEEE 802.1X with an appropriate Extensible Authentication Protocol and a RADIUS service. For supported equipment, assess WPA3-Enterprise as part of the security design. Define device compatibility before you mandate it. For residents, a private network bubble or individual pre-shared key can preserve separation between households without turning move-in into an IT project. The important control is not the label. It is the ability to issue, change, and revoke access without affecting every other resident. Do not confuse a captive portal with the whole security design. A captive portal is the splash page shown before an internet connection is granted. It manages login and can present terms or an opt-in choice. Purple recommends an open WiFi network for WiFi services when you want to reduce friction. Device operating systems generally use a Captive Network Assistant to recognise that internet access needs a login. The controller manages the interaction with the splash-page service, then passes the one-time login to RADIUS to complete access. That process can support a move-in experience. It does not replace segmentation, identity management, or a documented support model. Privacy needs a line in the requirements as well. If the WiFi journey collects information that identifies a resident, guest, or visitor, then your purpose, collection fields, retention, and responsibilities matter. The ICO says that UK GDPR principles include purpose limitation, data minimisation, storage limitation, integrity and confidentiality, and accountability. Write down whether the building, the operator, or both decide the purpose and means of processing. Use conscious-choice opt-ins. Do not collect demographic or marketing information by default merely because the login journey can ask for it. Here are two short real-world examples. In retail, Harrods used Purple Guest WiFi and a captive portal to support its Harrods Rewards programme. Purple reports that 581,317 unique individuals logged on over 12 months, 38% opted in to marketing communications, and 4,453 people signed up to Harrods Rewards after expressing interest in the login process. The procurement point is not that every building should copy a retail login flow. It is that the access layer, identity journey, consent, and business process must be designed together. At the Formula 1 Mexico City Grand Prix, Purple and partner Telmex used branded WiFi journeys at a mass sporting event. Purple reports 38,200 fan journeys, an 86% authentication rate, 6,700 new leads, and 18,000 redirections to the Telmex website. Again, this is a different operating environment from a BTR building. The transferable lesson is capacity planning with a defined access journey. Choose where an identity step adds value and where it creates delay. For your estate, select bulk internet when you want a single commercial relationship for service delivery and are content for the provider to operate most of the stack. Select resident-paid broadband when choice and separate consumer contracts matter more than a standardised move-in experience. Select managed WiFi when you need building-level control over access, segmentation, lifecycle operations, and the asset. In practice, hybrid designs are common. You might buy one building-wide circuit, own the structured cabling, and appoint a managed service to run WiFi while retaining the right to change the ISP. Before approval, run one final workshop. Bring property, IT, legal, security, finance, and operations together. Mark the fibre handoff, risers, switches, access points, cloud services, support desk, data roles, and billing owner on one diagram. Then simulate a Friday move-in, a lost device, an ISP fault, a resident leaving, an access-point failure, and contract expiry. If the owner and action are clear in each scenario, the model is probably workable. If they are not, do not sign yet. Rapid-fire answers. Can you move from resident-paid broadband to managed WiFi? Yes, but survey the physical network, confirm access rights, decide equipment ownership, design resident communications, and run a phased cutover. Is bulk internet always cheaper? No. Compare the full operating scope and exit exposure. Who owns the network? Only the contract tells you. Make it explicit. What makes a strong managed WiFi design? Separate identities, isolated traffic, documented lifecycle controls, monitored infrastructure, and a tested handover plan. The decision is not about choosing a label. The decision is not about choosing a label. It is about assigning ownership, operation, security, and resident experience to the party that can run each part well. Make that accountability visible before you sign. Thank you for listening.