keynet-cloud Swiss IT Security AG sells hosted capacity that still depends on racks, transit and repair windows

Summary

• Swiss IT Security AG is an active Swiss corporation and presently offers managed hosting, private cloud, backup, recovery and housing. A first-party customer account describes a Lucerne data centre, MPLS access, Cisco UCS blades and Pure Storage, which is meaningful operating evidence rather than a name alone.
• The network identity called keynet-cloud, AS48575, is registered but not currently announced. RIPE route history last saw its recent prefixes in February 2025. A separate company identity, AS44911 keynet-ag, currently announces one IPv4 /24 and one IPv6 /30 through one observed neighbouring network.
• The public record does not establish whether the advertised private-cloud service occupies one or several facilities, whether the Lucerne site is owned or leased, how much spare compute and storage is immediately usable, or whether customer systems have completed a measured second-site restoration.
• Customers should therefore evaluate a chain of dependencies: contracting entity, rack and power domains, CKW Fiber Services or any other carriers, address portability, spare hardware, named support coverage, backup isolation, recovery priority, billing continuity and a tested route out of the service.

A cloud identity survived a corporate merger, but its route did not

Keynet Cloud is neither an invented label nor a cleanly separable company today. The name is attached to AS48575 in the RIPE registry, whose organisation field now identifies Swiss IT Security AG. The same registry entity retains Keynet-era maintainers, contacts in Lucerne and the [email protected] abuse address. Yet RIPEstat's current overview of AS48575 says the number is not announced. Its routing-status result shows no visible IPv4 or IPv6 space, no observed neighbour and no visibility among the RIPE RIS collectors queried on 12 July 2026.

That is a significant change, not proof that the whole business has vanished. RIPEstat's route history records a long operating past and says that 185.156.220.0/23 and 185.156.222.0/24 were last visible in February 2025. Earlier address ranges extend the history back to 2009. The record therefore supports a network that once originated customer-relevant space and then withdrew its latest routes. It does not reveal whether workloads were retired, renumbered, moved behind another company ASN, transferred to a supplier or kept on private connectivity.

The legal identity is much less ambiguous. Switzerland's official UID register lists Swiss IT Security AG, UID CHE-114.608.384, as an active corporation and active VAT registrant at Etzelmatt 3 in Wettingen. It was not the original Keynet legal entity. Contemporary reporting says the Lucerne company Keynet AG, founded in 1996 and already part of the wider group, merged into Swiss IT Security AG in July 2021. Employees and customer contacts were supposed to continue, while the Swiss activities moved toward one name.

This history creates an easy analytical mistake. The dark ASN can be treated as evidence that Swiss IT Security AG has stopped operating, which is too broad. The active corporation and current service pages can instead be treated as proof that every old Keynet Cloud dependency continues unchanged, which is also too broad. The defensible conclusion sits between them: the company operates and markets infrastructure services, but the path from the legacy Keynet Cloud network to the capacity sold in 2026 has changed and is not publicly mapped in enough detail for a buyer to infer resilience.

Corporate continuity matters because the contracting party, invoices, support obligations and liability now sit with Swiss IT Security AG. Technical continuity matters separately because IP addresses, DNS, firewalls, virtual-machine networks and backup repositories may preserve older names long after a merger. A customer needs both stories reconciled. A contract signed by the current company should identify the present service platform, not rely on an obsolete brand as a substitute for facility and network facts.

The best operating evidence is a Lucerne customer installation

The strongest public account of what Keynet Cloud meant in practice is a Swiss IT Security customer case about Woodpecker Holding. The company's English account says six sites were connected by MPLS to a Swiss IT Security Cloud data centre in Lucerne. It describes business applications, Microsoft Active Directory, security services, hybrid Exchange, backup systems and a Citrix virtual-desktop environment. It also names Cisco UCS blade hardware and a Pure Storage full-flash array at the centre of the new infrastructure.

Those details materially improve the evidence grade. They locate at least one service delivery in Lucerne and connect the virtual product to identifiable classes of physical equipment. They show that the service was used for production workloads across multiple customer offices, not merely advertised as a future offering. They also identify who would suffer if the central platform failed: 180 desktop users, six connected sites and the business functions behind the hosted applications.

The case is not a current capacity certificate. It does not state when every component entered service, how many blade chassis were installed, which Pure Storage model was used, how much space remained, where backups were held, or whether a second production site could take the load. It calls the arrangement a centralized data centre. Centralisation can reduce the cost and inconsistency of equipment at six offices, but it also moves more consequence into the central site, its access circuits and its support team. The same architecture that simplifies management makes failure-domain design more important.

Swiss IT Security's current managed-services page confirms that infrastructure remains in the offer. It advertises Managed Azure & Datacenter, Managed Backup & Recovery, Managed Hosting, Managed Private Cloud and Housing Services. The page says dedicated environments and web services can run in the company's own data centre; customer hardware can be housed there with power, cooling and security; and private-cloud environments offer virtualisation, self-service and lifecycle management. It also advertises 24/7 operation and monitoring, defined service levels, automated backup, disaster recovery and regular restore tests.

These are current provider claims and should be read as claims. They do not name the data-centre building, disclose its owner, enumerate utility feeds, identify generator endurance, list carrier entrances, state rack power density or publish recent recovery measurements. The singular phrase “our data centre” is especially important. It confirms a physical service boundary, but it does not establish multiple independent sites. A buyer should not turn a broad claim of high availability into an assumption of geographic failover.

The public evidence therefore supports a live hosting capability at the company level, a historically documented Lucerne operating site and a service catalogue that still includes private infrastructure. It does not support a precise inventory of today's sellable capacity. That difference is the heart of the procurement problem: a supplier can truthfully operate a data centre while having limited headroom for one customer's urgent expansion or recovery.

AS48575 is dark, while AS44911 carries a narrow live edge

The company's routing picture becomes more informative when AS48575 is not viewed alone. RIPE also registers AS44911 under the name keynet-ag to Swiss IT Security AG. RIPEstat currently marks AS44911 as announced. Its routing-status view shows one IPv4 prefix with 256 addresses, one IPv6 prefix, full or nearly full collector visibility and one observed neighbour. The announced-prefix list identifies 185.156.223.0/24 and 2a07:a200::/30.

That live edge is reassuring in one respect. It shows that network resources registered to the same legal organisation are not wholly dormant. An address in the IPv4 range also appears in the SPF record for keynet.ch, tying at least one public company-domain mail permission to the active space. The legacy domain itself redirects visitors to the SITS website, consistent with the corporate integration rather than disappearance.

But a sibling ASN cannot silently stand in for the old one. AS44911's current neighbour result shows only AS198433. RIPE identifies that network as CKW Fiber Services AG. A public collector observes routing adjacency, not the commercial contract behind it, and it may miss private interconnection. Even with that caveat, one observed neighbour is not evidence of diverse upstream paths. The company has no current PeeringDB entry for either AS48575 or AS44911, so there is no self-maintained public facility, exchange or peering inventory to clarify the picture.

The active IPv4 prefix also has a revealing registration history. The broader 185.156.220.0/22 allocation belongs to Swiss IT Security AG. The first three /24 portions were associated with the old keynet-cloud naming, while 185.156.223.0/24 remains globally visible from AS44911. This looks consistent with consolidation or partial renumbering, but route data cannot prove the operational motive. It also cannot establish which customer systems use which portion of the allocation.

For a buyer, the practical questions are direct. Will the purchased service use provider IPv4 or IPv6 space, a customer's portable addresses, private MPLS addressing, or addresses belonging to a carrier or public cloud? Which ASN will originate public routes? If AS44911 is the edge, is CKW the only paid transit path, or are additional paths hidden from public observation? Are carrier circuits physically diverse from the building to separate points of presence? Can the service remain reachable when the one visible neighbour withdraws routes?

The route data supplies a useful downgrade without supplying a verdict. It says that the old public edge went dark after years of activity and that the visible replacement edge is small and appears topologically concentrated. It does not say the racks are empty. A credible bid should explain the transition and provide current diagrams, carrier orders, route-policy evidence and failover test results under confidentiality.

The public domains expose the same transition

Domain behaviour reinforces the split between maintained identity and production infrastructure. keynet.ch remains configured and directs web users to the Swiss SITS site. Its DNS uses Azure DNS name servers and its mail records include Microsoft protection endpoints. That is consistent with a merged organisation centralising public communication on larger suppliers.

keynet-cloud.ch behaves differently. Its apex resolves to 149.126.4.46, address space registered to Swiss host Cyon, and the returned page says in German that the requested domain is not configured on the server. Its authoritative delegation uses Amazon Route 53 name servers. Its mail exchange records still point to hosts named spamhunter1.keynet-cloud.ch and spamhunter2.keynet-cloud.ch, while its SPF record refers to 185.156.220.12, inside address space that is not currently visible in the global routing table.

The unconfigured page is a weak signal, not evidence that customer virtual machines are unavailable. A service domain can become a placeholder after marketing moves elsewhere while production continues under unrelated names. The DNS choices nevertheless show that the old public brand is not an ordinary live storefront. They also illustrate how dependencies can cross organisational boundaries: public pages at Cyon, authoritative DNS at Amazon, company mail at Microsoft and production hosting potentially in a company facility.

That diversity can improve resilience if it is deliberate. A status page hosted away from the production network can remain available during a data-centre outage. External authoritative DNS can continue answering if a provider edge fails. Separate mail delivery can preserve incident communication. Yet diversity of suppliers does not automatically create an effective incident channel. The public placeholder does not direct customers to a status page, emergency number or service notice, and the old mail hosts appear to rely on withdrawn address space.

Customers should confirm the exact out-of-band channels they will use. The support portal, status site, emergency telephone and authoritative DNS should not all require the failed production environment. Contact details should be tested from an external connection, and escalation authority should be clear enough that a night engineer can order a remote-hands intervention or carrier escalation without waiting for a sales contact.

The domain evidence also argues against treating names as infrastructure maps. keynet-cloud.ch is hosted at one external Swiss web provider; sits.ch is hosted at another; and the active company route is elsewhere. None identifies the customer compute location by itself. Data locality must be established at the workload, replica, backup, log and support-access levels, not inferred from a .ch suffix.

A data-centre location is not the same as an ownership boundary

The Woodpecker account locates a data centre in Lucerne. The current service page calls the hosting location the company's own data centre. Neither statement settles the property and operating chain. “Own” can mean a building owned by the provider, a dedicated suite in a colocation facility, leased racks controlled by the provider, or simply an environment operationally managed by the provider. Each model can deliver a sound service, but each assigns maintenance and failure responsibility differently.

If Swiss IT Security owns the facility, it may control switchgear, generators, cooling, physical access and carrier procurement directly. It also bears the capital cost and the risk that one site becomes underused or obsolete. If it leases a suite, the landlord may control utility maintenance and major plant while Swiss IT Security controls the racks and servers. If it rents racks, the service depends more heavily on the colocation operator's access rules, power density and remote hands. If it resells capacity, the company may control customer support and virtualisation but not the hardware or building.

The public record does not identify which arrangement applies to the Lucerne environment in 2026. The Wettingen registered office and the group's several Swiss office locations should not be mistaken for data-centre sites. An office address proves where an organisation can be contacted; it does not prove that production systems are installed there. Conversely, a Lucerne data-centre reference does not prove that the former Keynet office at Staldenhof 18 contains the server room.

The buyer should ask for the facility operator's legal name, municipality, site identifier and division of responsibilities. Evidence can include a colocation agreement summary, power single-line diagram, maintenance matrix, physical-access terms and current certification scope. The answer need not expose sensitive floor plans publicly. It does need to show who can restore power, approve access, replace a failed cooling unit and contact each carrier.

This boundary matters most during maintenance. A facility operator may announce a switchgear service window. Swiss IT Security then has to assess which power paths are affected, whether rack devices have dual supplies connected to separate distribution units, whether generators and uninterruptible systems remain available, and whether customer risk requires migration. If a subcontractor controls the window, the cloud seller cannot eliminate that dependency through a service-level clause. It can only design around it, communicate it and prove that the design works.

Installed hardware is not the same as capacity ready for a customer

Cisco UCS blades and a Pure Storage array are concrete assets, but a hardware list does not reveal capacity that can safely be sold. Installed compute includes processors and memory already committed to customers, reserved for failover, held for maintenance, consumed by the virtualisation layer or unavailable because of a fault. Installed storage includes replicas, snapshots, parity, metadata, spare space and performance headroom. A nominal terabyte is not necessarily a terabyte available for a new workload.

The provider's current private-cloud offer adds another layer. Self-service and virtualisation can make allocation quick, but they cannot create physical memory, flash endurance, network ports or licensed software. Elasticity inside a small private cloud depends on spare hosts and shared storage. When those reserves run low, the supplier must install hardware, move workloads or ask customers to wait.

This is where hosting economics meets reliability. Idle capacity protects recovery but earns little direct revenue. High utilisation improves asset returns but leaves less room when a host fails. Spare equipment reduces repair time but ties up capital and ages on the shelf. Multiple sites spread risk but duplicate network, security and operational costs. A smaller provider can make sensible choices, but customers cannot infer those choices from the phrase “scalable infrastructure”.

A useful capacity disclosure separates normal allocation, failure reserve and saleable headroom. For compute, it should show how many host failures the cluster can absorb while preserving customer reservations. For storage, it should show usable space after protection overhead and the performance effect of a controller or shelf failure. For networking, it should identify oversubscription and the smallest shared bottleneck. For backup, it should state repository consumption, retention, ingest limits and restore bandwidth.

Capacity also has a time dimension. A provider may be able to procure another blade in six weeks but unable to satisfy a recovery request tonight. “Available” should therefore mean installed, powered, licensed, connected and assignable within the service's recovery objective. Hardware on order, an empty rack or theoretical chassis slots are future options, not present recovery capacity.

The public evidence contains no figures at this level. That absence should not be converted into a claim that the company lacks headroom. It means the buyer must obtain a dated capacity statement and understand its measurement. For critical systems, the contract should protect reserved recovery capacity from being sold twice to several customers who are likely to need it during the same regional incident.

Power is the first shared physical dependency

Virtual machines disappear when their hosts lose power. The chain begins outside the rack: utility connection, transformers, switchgear, uninterruptible power systems, batteries, transfer switches, generators, fuel supply, distribution panels and rack power units. A nominally redundant data centre can still contain a shared component or maintenance state that places both paths at risk.

Uptime Intelligence's 2026 annual outage analysis says power remains the leading cause of impactful outages. It highlights UPS systems, transfer switches and generators, while also pointing to grid constraints and the pressure of denser workloads. The finding is industry-wide and says nothing about an incident at Swiss IT Security. It establishes why a procurement review should move beyond a generic availability percentage.

For the Lucerne service, the missing public facts include the number of utility feeds, whether they are truly independent, the generator topology, fuel autonomy, refuelling priority, battery technology, maintenance bypass design and rack-level A/B distribution. The Woodpecker case identifies a blade platform and full-flash array, both of which can have redundant internal power supplies, but redundant supplies only help if their cords reach separate live paths. A dual-corded server connected twice to one distribution unit still has one power domain.

Cooling belongs in the same analysis. A facility can retain electrical power and still shut down equipment if chilled-water, direct-expansion, pumps or controls fail. Dense blade and flash systems concentrate heat. The provider should state the design load, current load, cooling redundancy and conditions under which systems are throttled or shut down. A claimed empty rack is not useful headroom if the room lacks cooling or power for its full load.

Repair windows expose the operating design. The customer should see maintenance notices early enough to assess risk, understand whether redundancy is reduced during the work and know what happens if the remaining component fails. The supplier should identify blackout periods when customer changes are restricted and explain whether live migration is available. If a whole site must be placed at risk, critical workloads need an alternate location or an accepted business decision.

The evidence that would improve confidence is operational: recent integrated systems tests, generator starts under load, battery maintenance, failover events and post-maintenance reports. Certifications can help establish control discipline, but they do not replace the exact power path used by a customer's rack.

Transit concentration can isolate healthy machines

The physical server can be healthy while the service is unreachable. Fibre cuts, router faults, optical failures, route leaks, denial-of-service attacks, carrier maintenance and contract disputes all interrupt the network layer. The visible AS44911 topology raises this issue because RIPE RIS observes one adjacent network, CKW Fiber Services.

CKW is a plausible regional carrier for a Lucerne operation. RIPEstat identifies AS198433 as CKW Fiber Services AG, and the registry gives it a Lucerne address. That geographic coherence strengthens the interpretation that AS44911 has a real regional access path. It does not establish a second independent path. A second circuit bought from the same supplier can share ducts, optical equipment or an upstream route.

True diversity requires evidence at several levels. Fibre should enter through separate building routes. Access circuits should terminate on separate provider equipment. Edge routers should not share one power unit or one software fault. Upstream paths should avoid a common regional choke point where feasible. DNS and remote access should remain available during a route withdrawal. The customer should also know whether public addresses are originated directly by Swiss IT Security or carried inside a supplier's network.

AS48575's withdrawal adds migration risk. If customers once used addresses from 185.156.220.0/23 or 185.156.222.0/24, they may have needed renumbering when those routes ceased. Renumbering affects firewall allowlists, DNS, certificates, partner integrations, mail reputation and logs. A well-managed change can be uneventful, but it should leave a customer communication and rollback history. Prospective customers should ask whether any legacy Keynet Cloud addresses remain in private configurations or documentation.

Route security deserves attention too. RIPEstat's RPKI validation endpoint reports no validating route-origin authorisation for the two currently announced AS44911 prefixes, leaving their status “unknown” rather than valid. That does not make the routes illegitimate; many legitimate routes still lack a published authorisation. It means one useful control against accidental or malicious origin changes is not publicly demonstrated for these prefixes.

A transit failure test should therefore be concrete. Withdraw or disable one edge path under controlled conditions, measure convergence, confirm return traffic, test IPv4 and IPv6, and observe customer applications from outside the provider network. If only one upstream exists, the service description should say so and the recovery design should account for it rather than implying carrier diversity.

Hardware stock and repair labour determine the real recovery time

When a blade, storage controller, switch or firewall fails, recovery depends on more than a vendor warranty. Someone must detect the fault, diagnose the component, gain physical access, find a compatible spare, replace it, restore configuration and verify customer service. Each handoff adds time. At night or during a regional disruption, staff and parts become scarcer.

The provider's current managed-services page advertises continuous monitoring, automatic alerting and incident management. Those are useful commitments, but the public page does not specify which service tiers include a staffed response around the clock, which severities trigger physical attendance, or where spares are held. “24/7 monitoring” can mean an alarm is generated at any hour; it does not necessarily mean a qualified technician and replacement controller are on site.

The Woodpecker installation also shows vendor concentration within the platform. Cisco UCS and Pure Storage are mature enterprise products, but each requires compatible firmware, support entitlement and replacement components. A spare generic server cannot always replace a failed blade without reconfiguration. A storage array may remain online after one component failure, yet operate with reduced protection until the part is replaced. The repair objective should measure time to restored redundancy, not only time until the application responds again.

Labour concentration is an equal risk. Keynet brought about 30 employees into Swiss IT Security in 2021, according to merger reports. The broader company now presents a much larger specialist base, which can improve escalation and staffing depth. It does not prove that many people hold access rights and current expertise for the Lucerne platform. A critical service can still depend on two engineers who know an old network design.

Customers should ask for role coverage rather than employee totals: network, virtualisation, storage, backup, security, facility access and incident command. Each critical role needs primary and alternate coverage. Access credentials should be recoverable without one person. Vendor support contacts and serial entitlements should be current. A departure or illness should not suspend the only path to a console.

The spare-stock question should distinguish hot spares, on-site cold spares, regional vendor stock and best-effort procurement. It should identify components with long lead times and the supported hardware age. For a customer recovery reserve, the supplier should say whether an unused host is actually compatible and licensed. A repair window backed by those facts is much more credible than a general promise of rapid response.

Backup only matters when it can be restored outside the failure

Swiss IT Security advertises automated backup, disaster recovery and regular restoration tests. A separate first-party account of a 2022 ransomware response describes rebuilding a clean environment, recovering virtual machines and storage with Veeam and Commvault, reconstructing identity services and hardening the restored estate. The published recovery account shows practical incident experience, though it does not identify Keynet Cloud as the affected platform or publish measured recovery times.

The Swiss National Cyber Security Centre warns that cloud services offer limited protection from ransomware when data is stored only in the cloud. Protection depends on version recovery and stronger controls around access to those versions. The same principle applies to provider failure. A backup in the same administrative account, storage array, building or support domain can be lost or locked with production.

The buyer needs a map of every copy. That includes production data, local snapshots, backup repositories, off-site copies, configuration backups, encryption keys, identity services and logs. For each copy, the map should identify municipality or region, facility operator, network path, administrator, retention, immutability and deletion authority. “Georedundant” is not enough unless the second geography and shared dependencies are known.

Recovery tests must also match the promised unit of recovery. Restoring one file does not prove that an enterprise application, directory, firewall policy and dependent database can be restored together. Starting a virtual machine does not prove that users can authenticate or external partners can connect. A meaningful test records recovery-point loss, elapsed recovery time, data-integrity checks, application validation and the capacity consumed at the alternate location.

NIST's contingency planning guide recommends alternate storage, alternate processing, telecommunications resilience, backups and exercises aligned to business impact. It is US federal guidance, not a Swiss legal requirement, but the engineering questions are universal. The alternate site should be far enough away to avoid the same disruption and equipped to meet the required restoration time.

Priority during a shared disaster is especially important. A provider can test one customer's recovery successfully when the platform is quiet, then discover that many customers cannot all fail over at once. Contracts should state whether capacity is dedicated or pooled and how restoration order is decided. A customer with a strict objective needs reserved compute, storage and bandwidth, not only a place in a queue.

Data sovereignty requires a map, not a Swiss label

A Swiss company, a .ch domain and a Lucerne data-centre reference all support a Swiss service narrative. None proves that every processing activity remains in Switzerland. Public DNS uses Amazon and Microsoft infrastructure; public websites use external Swiss hosts; support and security products may involve other suppliers. Backups, telemetry, ticketing and remote administration can cross borders even when the primary virtual machine does not.

The Swiss Federal Data Protection and Information Commissioner describes cloud use as outsourced processing. Its cloud guidance says the customer remains responsible for lawful processing and should pay particular attention to processors, sub-processors, security and transfers to third countries. Its outsourcing guidance says controllers must select processors carefully, instruct them and monitor them where necessary.

For Swiss IT Security, that means a customer should obtain a current sub-processor list and location schedule. The schedule should separate primary compute, replicas, backups, security logs, support tickets, monitoring data and administrative access. It should name public-cloud components rather than letting the broad phrase “hybrid cloud” conceal them. It should also define how changes are announced and whether the customer can entity or exit.

Encryption changes exposure but not location. Customer-held keys can reduce provider access to stored data. They do not remove metadata, guarantee availability or solve recovery if keys are lost. A key-management service in the same administrative domain may fail with the workload. Sensitive customers should identify who can decrypt, where key backups reside and how keys are transferred during exit.

The current SITS privacy page identifies Swiss IT Security AG as the responsible company for its Swiss websites and provides a data-protection contact. That is helpful for public-site processing but is not a substitute for a service-specific processing agreement. A hosted customer's roles, purposes, retention and sub-processors differ from those of a website visitor.

Regulated customers also need incident communication fast enough to meet their duties. Since April 2025, covered Swiss critical-infrastructure operators must report qualifying cyberattacks to the NCSC within 24 hours of discovery. The NCSC's implementation notice makes the customer-provider information path consequential. A hosting contract should require timely facts, preservation of evidence and a named incident liaison without assuming that every hosted customer is itself covered.

Data sovereignty is therefore an operating property: location, access, law, subcontracting and exit all have to align. The phrase “own data centre” answers only part of that test.

Billing and provider-contract failure can be as disruptive as broken hardware

Infrastructure can remain technically sound while access fails for commercial reasons. An invoice dispute, lapsed support entitlement, landlord disagreement, unpaid carrier bill or mistaken account suspension can interrupt service. Corporate mergers add another risk: old order forms, brand names and technical contacts may not align with the legal entity that now issues invoices and controls assets.

The 2021 Keynet merger appears orderly in public reports. Customer contacts and locations were meant to remain, and Swiss IT Security AG is demonstrably active today. The issue is not evidence of a current dispute. It is whether each customer's contract has caught up with the changed operating model. A document still naming Keynet AG or relying on AS48575 may describe obligations that no longer match service delivery.

Customers should verify the contracting entity, VAT number, bank beneficiary, service schedule and asset boundary. The agreement should identify subcontractors whose failure can suspend service and explain whether Swiss IT Security can continue operating if a landlord or carrier contract ends. It should also distinguish a group marketing identity from the Swiss operating company. The SITS website imprint names Swiss IT Security Group AG, while the Swiss service and privacy pages identify Swiss IT Security AG in relevant contexts; buyers should ensure the correct entity signs the service commitment.

Suspension rights require proportional controls. A provider needs protection against persistent non-payment and abuse, but an immediate shutdown of critical systems can cause damage far beyond the disputed invoice. The contract should include notice, escalation, a cure period where lawful, preservation of data and controlled export. Security incidents may require faster action, but the supplier should define who can order isolation and how unaffected data remains retrievable.

Vendor support contracts form another hidden commercial layer. Cisco, Pure Storage, virtualisation and backup products may depend on active subscriptions or support. If an entitlement lapses, replacement parts, updates or recovery assistance may be delayed. Buyers do not need every invoice, but they do need assurance that critical entitlements are current and included in the price.

Financial resilience is difficult to infer from service pages. The official register proves active status, not cash reserves or the economics of the data centre. Critical customers should use proportionate financial due diligence and avoid prepaying more exposure than necessary. They should also preserve their own current copies of configurations, licences, data and documentation so a commercial shock does not become an irreversible technical lock-in.

Migration is the recovery path for failures the provider cannot fix

Every hosted service needs an exit that works before the customer wants to leave. Migration may be planned because of price or strategy, or urgent because the provider has a prolonged outage, contract dispute or capacity shortage. The urgent case is the demanding one: the management portal may be unavailable, support staff may be overloaded and network transfer may be constrained.

NIST's cloud synopsis and recommendations treats portability and interoperability as material cloud concerns. Standard interfaces and data formats help, but private-cloud environments often contain virtual-machine formats, network policies, snapshots and managed services that are not directly portable. A customer must know what the provider can export and what must be rebuilt.

The exit package should include data in a documented format, virtual-machine images where contractually permitted, firewall and load-balancer configurations, DNS records, identity dependencies, certificates, logs and backup catalogues. It should include checksums and enough metadata to verify completeness. Encryption keys must be included or transferred under a separately tested method. The package should not depend on the continued availability of the provider portal.

Bandwidth makes portability physical. Exporting tens of terabytes across a congested circuit can take days. A buyer should measure realistic egress speed and decide whether encrypted media transport is available. If physical media is an option, the contract should specify compatible devices, custody, shipping, return and secure erasure. If only network export is allowed, bandwidth should be reserved during an incident.

Addressing is another barrier. Customers using provider addresses may have to update DNS, allowlists, VPN peers and partners. Those using their own portable addresses need confirmation that routing can move cleanly. The AS48575 withdrawal is a reminder that network identities change even when a company continues. A migration exercise should include address transition and certificate validation, not only copying disks.

Exit assistance has to survive termination. The service schedule should set a retrieval period, support rates, deletion timing and the order in which copies are erased. The customer should receive evidence of deletion only after confirming that the export is usable. If the provider fails financially, ordinary termination language may be limited public evidence; escrowed documentation, customer-held backups and an alternate service contract can reduce dependence.

The strongest proof is a partial migration completed in normal times. Restore a representative application with another provider or on customer-controlled hardware, reconnect identity and network dependencies, and measure the result. That exercise turns portability from a clause into a recovery capability.

Who is affected when one service domain fails

The Woodpecker case makes the affected population tangible. A central platform supported users at six sites and hosted line-of-business applications, identity, backup, security and virtual desktops. If that platform became unavailable, the harm would not stop at an IT team. Employees could lose desktop access, business applications and authentication together. Customers and suppliers could encounter delayed orders, communications or fulfilment.

The same concentration can occur for any managed-hosting customer. A provider may operate compute, storage, network security, backup and support as one convenient package. Operationally, that reduces the number of vendors the customer coordinates. Structurally, it can place several recovery controls inside one company and one facility. The customer should identify which controls remain independent.

The provider's own staff are affected too. During a wide incident they must diagnose infrastructure, communicate with customers, coordinate facility and carrier suppliers, preserve security evidence and manage restoration priority. If support tools depend on the failed service, their task becomes harder. Out-of-band communication and externally stored operating documentation protect the provider as well as customers.

Data subjects face a different consequence. Unavailability can delay services; corruption can produce wrong decisions; unauthorised access can create privacy harm. Recovery must preserve integrity, not simply restart machines. Customers should validate transaction consistency and reconcile data after restoration.

Regional concentration can affect several customers simultaneously. A power or fibre incident in Lucerne may create many urgent cases. Pooled spare capacity and support staff then face correlated demand. Service levels written as if each customer fails alone may not describe this condition. The supplier should explain regional disaster priority and the amount of capacity reserved for concurrent recovery.

The cost can exceed the hosting invoice. Uptime's 2026 analysis says 57 per cent of respondents reported their most recent major outage cost more than $100,000, while one in five placed an impactful outage above $1 million. Those survey figures are not a forecast for Swiss IT Security or any particular customer. They explain why buyers should size resilience spending against business exposure rather than monthly service fees.

Dependency mapping turns this into an actionable decision. For each critical service, identify users, business process, maximum tolerable outage, data-loss tolerance, provider component, facility, route, backup and alternate method. The result shows whether a Keynet-derived private cloud is an appropriate primary platform, a secondary environment or a service that needs stronger external recovery.

Evidence that would justify a stronger confidence grade

The current evidence supports a Medium network grade. The company is active, the service offer is current, a detailed customer account locates real infrastructure in Lucerne, and AS44911 provides a live company network edge. Confidence remains capped because AS48575 is dark, the visible active edge has one observed neighbour, PeeringDB provides no independent facility declaration, and current public materials do not establish multi-site capacity or measured restoration.

The first improvement would be a dated architecture statement. It should name the production and recovery municipalities, facility operators, ownership model, rack power domains, carriers, edge ASNs and address ranges. It should explain the February 2025 AS48575 withdrawal and identify whether customer services moved to AS44911, private MPLS, another supplier or retirement. The statement should distinguish public cloud, company private cloud and customer-owned equipment.

The second would be operating capacity evidence: installed compute and storage, current committed use, failure reserve, saleable headroom, spare hardware and expected replenishment time. Figures can be provided confidentially and in ranges. They should still be dated and tied to the actual service cluster.

The third would be resilience results. Provide recent power and carrier failover records, a representative full-application restoration, measured recovery point and time, second-site capacity and the number of concurrent customers included. Document failures and corrective actions as well as successes. A perfect claim with no test detail is less useful than a candid result followed by remediation.

The fourth would be contractual clarity. The signed Swiss operating entity, facility and network subcontractors, data locations, service hours, escalation path, suspension terms, recovery priority and exit assistance should align. Legacy Keynet names can remain useful identifiers, but they should not create ambiguity over responsibility.

The fifth would be customer-verifiable portability. Give the customer periodic exports, configuration copies, key custody options and enough bandwidth or media support to restore elsewhere. Test at least a representative service away from the provider's primary environment.

Until those items are supplied, procurement should be proportionate. The evidence does not justify declaring the service unavailable or the company inactive. It does justify limiting concentration, retaining an independent backup, requiring explicit location and carrier facts, and treating geographic recovery as unproved. Keynet Cloud's history shows the real substance behind hosted capacity: servers, flash arrays, MPLS circuits and engineers. Its present ambiguity shows why those assets must be mapped again after brands, routes and contracts change.