certit-hosting Certit Hosting Handelsbolag sells hosted capacity that still depends on racks, transit and repair windows

Summary

• Certit Hosting Handelsbolag is tied to AS43021 in RIPE records. RIPE RDAP shows the autonomous-system name as certit-hosting, and RIPEstat's AS overview lists the holder as certit-hosting Certit Hosting Handelsbolag.
• Current public routing evidence is weak. RIPEstat routing status for AS43021 reported no v4 or v6 RIS peers seeing announcements at the query time, and RIPEstat announced-prefixes returned no current prefixes for AS43021.
• Historical network resources matter but should not be overread. RIPE records tie 193.200.208.0/24 and 2001:678:cbc::/48 to the Certit organisation, while RIPEstat history shows those resources were seen in the past and RIPEstat last-seen routing status points to the IPv6 prefix in April 2026.
• The company-facing service story is split. www.certit.se still exposes Certit Hosting pages for cPanel hosting and KerioConnect mail, while the apex certit.se serves Ayaa IT-konsult content for managed IT, webhosting, VPS, backup, network services and support from Borlange.
• The operating-risk question is not whether the brand once sold hosting. It is whether today's customer workloads have active facility placement, transit diversity, spare hardware, restore tests, escalation paths and data portability that can survive rack, upstream, support, billing or migration failure.
• The network evidence grade is Weak. The public record establishes identity and historical operation, but current public BGP visibility does not prove live hosted capacity.

The cloud bill still ends at a rack

A hosting invoice can make infrastructure look neat. It turns servers, storage, operating systems, control panels, email queues, IP addresses, monitoring, backups and support labour into one commercial service. The user logs in, uploads files, creates mailboxes, starts a virtual server or asks support to restore data. Underneath, the service still depends on physical sites, power, racks, disks, router ports, upstream networks, domain administration and people with authority to act.

That is the right way to read Certit Hosting Handelsbolag. The public record is real enough to study. RIPE RDAP lists AS43021 with the name certit-hosting and a registrant entity for Certit Hosting Handelsbolag. RIPEstat's AS overview gives the holder as certit-hosting Certit Hosting Handelsbolag. Those records anchor the identity.

They do not, by themselves, prove that a given webhosting customer is sitting in a particular Swedish data hall today. They do not say whether the current service is still carried over AS43021, over an upstream provider's address space, over a third-party platform, or over a managed-services stack branded under Ayaa. Public route data tells us where to start asking questions, not where to stop.

That distinction is central because Certit's current public footprint is mixed. The older Certit site at www.certit.se still presents a Certit Hosting brand and links to hosting, KerioConnect, about and contact pages. Its hosting page describes cPanel-based hosting, email accounts, access controls, domains, file management, MySQL databases, log utilities and annual hosting packages with storage, transfer and mailbox limits. Its KerioConnect page describes hosted mail and collaboration, including SSL encryption, S/MIME, anti-spam, antivirus and twice-daily backup of all data.

At the same time, the apex domain certit.se serves an Ayaa IT-konsult page. The Ayaa content describes business IT services, Microsoft 365, backup, webhosting, VPS, network services and personal support from Borlange; the same Ayaa site has dedicated pages for webhosting, VPS, backup, network-as-a-service and contact details. That does not prove a corporate transaction, a migration or a shared operating platform. It does show why a buyer cannot treat the name on the ASN, the older Certit hosting site and the Ayaa service site as one uninterrupted proof of current hosted capacity without a live contract and technical map.

The risk is ordinary but important. A small provider can deliver good service if it is honest about its dependencies, keeps spare capacity, tests restores and escalates quickly. A large provider can fail customers if it hides brittle physical arrangements behind a polished portal. Certit belongs to the first kind of question: the public evidence is thin enough that a buyer should verify the machinery before relying on the abstraction.

What the company pages say, and what they do not say

The older Certit hosting page is specific about customer-facing functions. It says the hosting service uses cPanel as the control panel. It describes email-account creation, forwarding, autoresponders and filtering; directory password protection, IP-level access lists, SSL/TLS and GnuPG; subdomains, add-on domains, parked domains and DNS management; file handling; MySQL database creation and phpMyAdmin administration; and Webalizer and AWStats log visibility. The same page lists package sizes: small, medium and large plans with different storage, domains, mailboxes, transfer and MySQL counts.

Those details matter because they describe the customer dependency surface. A cPanel hosting customer does not only depend on a web server. The customer depends on DNS, mail, database storage, TLS certificate handling, account state, control-panel availability, log retention, backup policy and support access. If any one of those layers fails, the customer may experience the failure as "the website is down" even when the real broken part is a mailbox queue, a database disk, a firewall rule, a suspended account or a certificate renewal path.

The KerioConnect page adds a second dependency surface: hosted mail and groupware. It describes mail, contacts, calendars, reminders and webmail across devices, plus encryption, anti-spam, antivirus and backups twice per day. That is more sensitive than static webhosting. A mail platform holds business correspondence, calendar state, contacts, legal notices, password-reset paths and sometimes customer support queues. If it fails, the blast radius reaches well beyond a homepage.

The Ayaa pages broaden the offer. Ayaa's home page presents managed IT, network, Microsoft 365, security, backup, AI, system development and webhosting. The webhosting page repeats a cPanel-hosting proposition and says the service includes Swedish operation, daily backup and personal support. The VPS page describes virtual servers with 99.9 percent uptime, firewall, automatic backups, DDoS protection, monitoring, managed or self-managed options, root access, SSD storage and dedicated resources. The backup page says Ayaa uses Acronis Cyber Protect, mentions server, virtual environment, NAS, file server and client backup, and frames recovery through RTO and RPO. The network service page describes managed firewalls, WiFi, monitoring, updates and a monthly service arrangement.

That collection is useful, but it is still product copy. It does not name the data centre. It does not publish a rack count. It does not state whether Certit-owned servers, leased racks, reseller hosting, hyperscale cloud or another Swedish infrastructure supplier hosts each product. It does not show a BGP path map, current upstream contracts, cross-connect diversity, power feeds, spare-parts location, hypervisor cluster size or backup-restore evidence. A buyer should treat it as a menu of claimed services and then ask for the operating proof behind the service they intend to buy.

This is not a criticism unique to Certit. Most small and mid-sized IT providers do not publish facility diagrams on a public website. The point is that a hosting article should not fill that silence with assumptions. If a page says "daily backup," the right next question is restore scope, retention, isolation, test cadence and export time. If a page says "99.9 percent uptime," the next question is whether that applies to VPS compute, the control panel, storage, network reachability, support response or all of them together.

AS43021 is a useful identity anchor, not current capacity proof

AS43021 is the network identifier that makes Certit visible in public routing databases. RIPE RDAP for AS43021 shows active status, the name certit-hosting, registration in 2007 and last-changed data from 2018. RIPEstat's whois view adds route-policy lines: imports from AS13189 and AS8473 accepting any, plus imports from AS9088, AS15893, AS39708 and AS16117; exports announce AS43021 to those ASNs. It also shows the status as assigned and the same Certit organisation reference.

Those import and export lines are important but dated. They indicate a declared routing policy in the public RIPE database, not necessarily the present commercial or physical topology. A provider may leave old route policy unchanged after changing upstreams, ceasing public announcement, moving customers to another carrier or shifting delivery onto a supplier network. That is why route policy should be compared with current BGP visibility.

The current visibility check is weak. RIPEstat routing status reported no v4 RIS peers and no v6 RIS peers seeing AS43021 at the query time, with zero announced v4 prefixes, zero announced v6 /48s and zero observed neighbours. RIPEstat announced prefixes returned an empty prefix list for the latest two-week window. RIPEstat ASN neighbours similarly showed no visible neighbours in the latest view. PeeringDB's ASN query returned no network entity for AS43021.

That does not mean there is no service. A hosting company can serve customers using addresses originated by an upstream provider, addresses inside a data-centre operator's network, a cloud platform, or a supplier-owned managed stack. Public BGP will not always reveal reseller delivery. But it does mean AS43021 should not be cited as proof that Certit currently operates customer-facing internet edge capacity under its own visible ASN.

For buyers, this changes the procurement test. Instead of asking "does the provider have an ASN?", ask "which ASN carries my workload today, which prefixes will be announced, who originates them, what happens if that upstream path fails, and what route-origin controls exist?" If the answer is "we do not use AS43021 for this product," that can be fine. The customer then needs the same evidence for the actual carrier and platform.

The IPv4 and IPv6 resources show history and limits

The IPv4 resource associated with the Certit organisation is 193.200.208.0/24. RIPE RDAP names the network gong-networks, marks it as assigned provider-independent address space, and includes Certit Hosting Handelsbolag as the organisation. RIPEstat's whois view for the prefix shows country SE, the same organisation reference, created in 2007 and last modified in 2016. RIPEstat's prefix overview, however, says the prefix is not currently announced in the checked public view.

The IPv6 resource is 2001:678:cbc::/48. RIPE RDAP names it SE-LIDEN-20200312, marks it as assigned provider-independent IPv6 space, and includes Certit Hosting Handelsbolag as the organisation. RIPEstat's whois view for the IPv6 prefix shows country SE, the Certit organisation reference and a 2020 creation date. RIPEstat's prefix overview also says the prefix is not currently announced in the filtered view, while noting one low-visibility route was filtered. A secondary public check at bgp.tools also reported that the IPv6 prefix was not in the global routing table and listed AS43021 with a last-seen date in April 2026.

RPKI adds another limit. RIPEstat route-origin validation for 193.200.208.0/24 originated by AS43021 returned an unknown state with no validating ROAs. The same was true for 2001:678:cbc::/48 originated by AS43021. Unknown is not the same as invalid, and a route that is not currently visible cannot be judged the same way as a live production route. Still, if a provider intends to originate these resources again for customer service, route-origin authorization should be part of the readiness requirements.

The history is therefore credible but not enough. RIPEstat's routing history shows long historical visibility for the IPv4 /24 and later visibility for the IPv6 /48. RIPEstat routing status shows first-seen AS43021 activity with 193.200.208.0/24 in 2007 and a last-seen item for 2001:678:cbc::/48 in April 2026. That is evidence that Certit's number resources have existed and were observed over time. It is not evidence that customer workloads are currently reachable, redundant or recoverable through those resources.

In infrastructure terms, this is the difference between installed history and usable capacity. A /24 in a registry is a useful asset. A /48 IPv6 assignment can support modern dual-stack architecture. But the customer only benefits if those resources are active, monitored, authorized, routed over sufficient upstreams and connected to the servers that hold the workload. Dormant or low-visibility resources are a reason for verification, not a substitute for it.

Transit diversity has to be current, not inherited

The public RIPE route-policy lines for AS43021 name several potential counterparties. On paper, that looks broader than a single-homed network. In practice, the current RIPEstat neighbour view shows no visible neighbours. The difference matters because routing policy can remain in a database after the physical and commercial topology changes.

There are four different kinds of diversity a customer should separate. Route diversity means the BGP control plane has alternative paths. Carrier diversity means those paths are with separate commercial suppliers. Physical diversity means cables, meet-me-room cross-connects, building entries, power strips and router shelves do not fail together. Capacity diversity means the remaining path can carry the customer load after the first path fails. A public AS entity rarely proves all four.

For Certit, the declared route policy might tell a historical story about earlier upstreams and peers. It does not prove that the current Certit or Ayaa hosting products have two active upstreams, two routers, two facilities or enough spare commit to ride through a fault. The current absence of public neighbours means the safest reading is "unverified."

This is where routing-security standards provide useful context. RFC 7454 describes operational practices for BGP security and filtering. RFC 6811 describes route-origin validation. MANRS frames routing security as a set of operational commitments for network operators. Those sources do not certify Certit. They explain why a buyer should ask for prefix filters, route-origin validation, upstream diversity, incident contacts and leakage controls if the provider is going to carry production workloads.

Transit diversity also has a support component. If the provider uses an upstream's address space rather than its own ASN, the customer needs to know who can open a carrier ticket, who can request rerouting, who can see packet-loss telemetry and who decides whether a fault is inside the provider, the carrier, the data centre or the customer's own configuration. A small provider with strong escalation can outperform a larger provider with a confused chain. But that strength must be shown, not inferred.

The practical test is simple. Ask for the current public prefixes, origin ASNs, upstream providers, looking-glass or route-monitoring evidence, RPKI state, change-window policy and the last successful failover test. If the provider cannot share all details publicly, it can still share them under contract. If it cannot share them at all, the customer should size the service as a convenience layer, not as a critical resilience layer.

Facility and power evidence is the missing centre

The strongest public gap is facility placement. The Certit pages give Swedish contact information. The older about page lists Certit Hosting Handelsbolag, a Borlange address and organisation number 969730-3809. The older contact page lists Certit Hosting, Box 811, 781 28 Borlange and [email protected]. The Ayaa contact page lists Vattugatan 3, 784 33 Borlange, a telephone number and support framing. Those details help place the business in Sweden and in Borlange. They do not place the servers.

For webhosting and VPS, the facility facts decide the repair clock. A failed disk is not a cloud abstraction; it is a part that must be replaced or worked around. A failed top-of-rack switch can disconnect many customers at once. A failed cross-connect can make a healthy server unreachable. A failed storage controller can break both web files and databases. A failed power feed can expose whether redundancy is real or only brochure language.

The public Certit and Ayaa material does not say whether customer workloads run in an owned room, a leased rack, a colocation cabinet, a reseller platform, a hyperscale cloud tenant or a supplier-managed hosting environment. Each arrangement can be reasonable. Each has a different failure path. Owned racks create direct responsibility for spares, access and power. Leased colocation creates dependence on the facility operator and remote hands. Reseller hosting creates dependence on an upstream provider's platform and account relationship.

Cloud delivery creates dependence on region choice, control-plane access, billing state and configuration discipline.

The customer should ask for the facility boundary in plain language. Where is the primary workload? Where is the backup? Where is the management plane? Who owns the servers? Who owns the switches? Who owns the IP addresses used by my service? Which parts can Certit or Ayaa repair directly, and which require a supplier ticket? What is the worst credible time from alarm to qualified hands on the failed component?

That set of questions is not excessive for small-business hosting. A small business that uses hosted mail, hosted databases or a VPS for accounting, bookings, ecommerce or customer support can be materially harmed by a long outage. The smaller the public footprint, the more important the private evidence becomes.

Installed capacity is not the same as usable capacity

The older Certit hosting packages describe storage, domains, mailboxes, data transfer and MySQL counts. The Ayaa pages describe VPS resources, SSD storage, root access, firewall, monitoring and managed maintenance. These are service units, not capacity proofs. A customer sees package limits; the provider must manage the oversubscription, backing storage, backup targets, support queue and repair inventory behind those limits.

Installed capacity is what exists under normal conditions. Usable capacity is what remains after a component fails. Recoverable capacity is what can be restored inside the customer's deadline. A host can have enough disk for normal operations but not enough spare hardware to evacuate a failed node quickly. It can have backups but not enough restore bandwidth to recover several customers at once. It can have two nominal upstreams but not enough commit on the second to handle peak traffic. It can have a support promise but only one person authorized to make the key change.

For Certit, the current public network evidence does not show a live ASN edge, and the website evidence does not show the hosting platform behind the plans. That means the installed-versus-usable question has to be answered through present operational documentation. A buyer should request current resource pools: the hypervisor cluster if buying VPS, the storage pool if buying webhosting, the mail-store topology if buying Kerio or another hosted mail service, and the backup target if buying managed backup.

It is also important to ask whether capacity is local, regional or outsourced. A Swedish service may use Swedish support but non-Swedish storage. A Borlange contact address may not mean a Borlange data hall. A cPanel service may be on a shared hosting server controlled by a third party. A VPS may be a virtual machine on the provider's own platform, a rented node or a cloud instance. The customer does not need to reject any of those options. It does need to know which one it is buying.

The control-panel layer deserves special attention. cPanel can make account management efficient, but it can also become a single point of customer dependence. If cPanel is unavailable, can support still restore files, rotate credentials, export databases, change DNS or disable a compromised mailbox? If the account is suspended or billing is disputed, can the customer still retrieve data? If the server is compromised, are backups isolated enough to avoid being overwritten?

Those questions turn package size into resilience. The most important capacity number is not the number of mailboxes on a plan. It is the amount of clean, tested capacity that remains available when the first part of the stack is broken.

Backup claims need restore evidence

The Certit KerioConnect page says backups of all data are taken twice per day. The Ayaa backup page talks about Acronis Cyber Protect, server and virtual-environment backup, NAS and file-server backup, client backup, cloud backup, 3-2-1 strategy, encryption, central monitoring, RTO, RPO, long-term archiving and disaster recovery planning. These are the right topics for a hosting dependency article because backup is where marketing claims meet the customer's survival plan.

But backups are not resilience until they have been restored. A twice-daily backup schedule says something about possible recovery points. It does not say whether the backup is offsite, immutable, encrypted, separated from production credentials, tested, complete, fast enough to restore, or available after contract termination. A 3-2-1 description is sound in principle, but the customer still needs to know where each copy sits and who can access it.

The mail case is especially important. Mail recovery is not just file recovery. A mail restore may need mailboxes, folder state, calendar entries, contacts, distribution lists, DNS records, authentication settings, spam-filter rules and client configuration. A partial restore can keep the server running while leaving users unable to work. The backup promise should therefore be paired with a restore drill that includes real user work.

The VPS case is different. A VPS backup may restore a whole image, selected files or application data. The customer needs to know whether a restore returns the same IP address, whether DNS changes are needed, whether the firewall rules and snapshots are preserved, whether databases are crash-consistent or application-consistent, and how long it takes to move from backup media to a running service. The answer can vary by plan.

The webhosting case is different again. cPanel backup can be convenient, but the customer needs to know whether it includes mail, databases, files, DNS zone files, SSL certificates, cron jobs and account-level settings. It also needs to know whether the restore can be performed if the cPanel instance itself is unavailable.

This is where a small provider can show seriousness. A short restore report is more valuable than a large uptime claim. It can say: what was restored, when, from which backup, by whom, how long it took, what failed, what was excluded and what the customer had to do after the restore. Without that evidence, backup remains a claim.

Data locality is not solved by the country code

The assignment region is Sweden, and the public records support a Swedish identity. The older Certit pages list Borlange contact information and a Swedish organisation number. RIPE prefix records for 193.200.208.0/24 and 2001:678:cbc::/48 show country SE and a Certit organisation reference. Ayaa's pages present Swedish-language managed IT services from Borlange.

Still, data locality is not settled by the country code in a registry or a postal address on a website. Customer data can be split between web files, databases, mail stores, backups, support tickets, logs, DNS providers, monitoring services, security platforms and billing systems. Some may be in Sweden, some elsewhere in the EU, and some in global platforms. A company can deliver Swedish support while using a non-Swedish backup repository or a third-party email filtering provider.

For customers with data-sovereignty requirements, the placement matrix should be explicit. Where is production data stored? Where are backups stored? Where are logs stored? Where are support tickets stored? Which subcontractors can access customer systems? Which legal entity signs the contract? Which jurisdiction governs disputes and data access? What happens if the customer asks for deletion, export or evidence of destruction?

The older Certit general terms PDF is linked from the Certit about page at Allmanna_villkor.pdf. Its public existence matters because service terms often contain the real allocation of responsibility: acceptable use, payment, suspension, customer data, liability, support and termination. A buyer should review current terms directly with the provider, because a 2009-last-modified PDF link and a 2024-updated website may not reflect the current operating arrangement.

Data portability is part of locality. It is not enough to know where data is stored while the service is healthy. The customer needs to know how to leave. Can it export mailboxes in standard formats? Can it export cPanel accounts, databases, DNS zones, SSL materials and logs? Can it get a full VPS image or only file-level data? How long after termination does access remain? What happens if the account is suspended for billing reasons while the customer still needs its data?

The answer decides whether hosted capacity is a service or a trap. A provider can be small and trustworthy, but the customer should not discover its exit route during a fault.

Support labour is part of the infrastructure

Ayaa's public pages repeatedly emphasize personal service, a dedicated contact person and quick support. The Ayaa contact page lists weekday hours and says there is 24/7 support for critical systems. The older Certit contact page says the fastest way to reach Certit is email. Both signals are operationally relevant because support is not separate from infrastructure. It is the mechanism that turns monitoring into repair.

The support path should be mapped before an incident. Who receives the alarm? Who can log in? Who can call the data-centre operator? Who can approve an emergency change? Who can restore a backup? Who can communicate to customers if the same mail service is down? Who can unlock an account if billing state blocks access? If the answer depends on one person, the customer needs to understand vacation, illness and after-hours coverage.

Support also determines whether the provider can distinguish failures. A website outage may be a DNS problem, a database problem, a TLS problem, a storage problem, a route problem, a firewall problem, a compromised account or a payment suspension. Fast support is not just fast reply; it is fast classification and authority to act.

For Certit, the public footprint does not publish a status page, incident history, escalation matrix or service-level detail. That is normal for many small providers, but it increases the importance of contractual support evidence. Customers should ask for contact methods, incident severity definitions, response and restoration targets, after-hours escalation, supplier escalation, maintenance notice policy and post-incident reporting.

This is not bureaucracy for its own sake. Hosted services often fail at the administrative boundary. A domain expires, a mailbox is locked, an invoice dispute suspends an account, a control-panel password is lost, a supplier ticket is misrouted, or the person who knows the environment is unavailable. These failures are just as real as broken disks.

The strongest small-provider advantage is local knowledge. A dedicated consultant who knows the customer can solve problems faster than an anonymous queue. The weakest small-provider risk is concentration. The same personal knowledge can become a single point of failure. Good support design keeps the first advantage without accepting the second.

The main failure paths are ordinary and testable

The most likely failure paths for Certit-style hosted capacity are not exotic. The first is rack or platform failure: a host node, storage shelf, switch, power feed or virtualisation stack fails. The second is upstream or route failure: traffic cannot reach the service because a carrier, prefix, BGP session or firewall path breaks. The third is hardware-stock failure: a broken part can be identified but not replaced quickly. The fourth is support failure: the right person or supplier cannot be reached in time. The fifth is billing or account failure: a service is suspended, a domain is not renewed or a supplier relationship is interrupted.

The sixth is migration failure: the customer tries to leave or move during stress and discovers that exports are incomplete, slow or unavailable.

Each path has a corresponding test. Rack and platform risk can be tested with node-failure exercises, capacity headroom and spare-parts evidence. Route risk can be tested with current prefix monitoring, upstream failover and RPKI state. Hardware-stock risk can be tested with spare inventory and remote-hands arrangements. Support risk can be tested with escalation drills and after-hours contact. Billing risk can be tested with account-continuity rules and supplier-contract clarity. Migration risk can be tested with real exports and restore to a separate environment.

The public evidence around AS43021 makes the route test especially important. If Certit no longer uses AS43021 for current hosting, the buyer should ask which network does carry the service. If it does use AS43021 intermittently or for selected resources, the buyer should ask why current public route collectors do not show stable announcements and how production reachability is monitored. If it plans to re-announce the IPv4 /24 or IPv6 /48, the buyer should ask for ROAs, filters, upstream confirmation and a change plan.

The public evidence around service pages makes the restore test equally important. cPanel, KerioConnect, VPS and backup are all restore-heavy services. A customer should not accept "we have backups" as a final answer. It should ask for proof that a mailbox, a website, a database and a virtual server can be restored inside the promised window.

The public evidence around the Ayaa transition or parallel surface makes the contract boundary important. If the customer signs with Ayaa for a service historically associated with Certit, it should know which legal entity, brand, support desk, platform and terms govern the service. That clarity matters when things are healthy, and it becomes decisive when a supplier must act under pressure.

Who is affected when it fails

The affected parties depend on the product. A small webhosting account may affect a local business website, form submissions, appointment pages and email tied to a domain. A cPanel account with mailboxes can affect password resets, invoices, customer support, newsletter delivery and internal operations. A KerioConnect account can affect calendars, contacts and collaboration. A VPS can affect a bespoke application, API, database, development environment or ecommerce back end. A managed backup service can affect the customer's ability to recover from ransomware or hardware loss.

These are not all equal. A marketing website outage may be tolerable for hours. A mail outage during a business day may block operations quickly. A VPS outage for a line-of-business application may be critical within minutes. A backup failure may not be noticed until the day it is needed, which makes it especially dangerous. The provider should not sell one generic resilience story to all customers.

The customer should classify workloads by dependency. Which services are public-facing? Which hold regulated or sensitive data? Which are needed to communicate during an outage? Which have a manual workaround? Which can be rebuilt from code and configuration, and which contain irreplaceable user-generated data? Which exports have been tested? A small provider can support that classification well if it knows the customer environment, but it needs to write the assumptions down.

The provider should also state which failures are outside its control. If the customer controls DNS, the provider may not be able to fix a wrong DNS change. If an upstream data centre controls remote hands, the provider may not be able to shorten a physical repair beyond the supplier's queue. If a third-party cloud platform hosts the VPS, the provider may be coordinating rather than repairing directly. Honest boundary statements are not weakness; they are the basis of realistic recovery.

For Certit, public evidence supports a cautious conclusion. The company identity and service history are visible. The current public routing signal is weak. The service pages indicate hosting, mail, VPS, backup and support offerings, but not the underlying facility and network proof. Customers affected by failure should therefore require current, product-specific resilience evidence before treating the service as critical infrastructure.

What would improve confidence

The evidence grade could improve with a small set of public or contract evidence. First, current route evidence: active originated prefixes, origin ASNs, upstreams, RPKI ROAs, route filters and independent monitoring. Second, facility evidence: the operating arrangement for hosting and VPS, whether workloads run in owned racks, colocation, reseller hosting or a cloud platform, and where primary and backup data are located. Third, redundancy evidence: two-path design, failover tests, capacity headroom and what remains usable after the first fault.

Fourth, restore evidence: recent successful restore tests for web files, databases, mailboxes and VPS images. Fifth, support evidence: escalation contacts, after-hours coverage, supplier escalation and incident communication process. Sixth, portability evidence: data-export formats, timelines, costs and access after termination.

None of that requires publishing sensitive diagrams to the open internet. A provider can share precise details under contract and keep public pages simple. The important point is that the customer gets present evidence, not inherited comfort from a 2007 ASN registration or a hosting page refreshed in 2024.

The current public record also suggests monitoring tasks. Watch AS43021's RIPEstat overview and routing status. Watch 193.200.208.0/24 and 2001:678:cbc::/48 for announcements and RPKI state. Watch whether www.certit.se remains a Certit Hosting WordPress surface while certit.se remains an Ayaa surface. Watch whether the terms, contact pages and service pages converge, redirect or change. Watch whether PeeringDB gains a profile or whether public route collectors begin seeing stable upstreams again.

Those monitoring tasks do not prove customer safety by themselves. They help detect when the evidence changes. If the ASN returns to stable announcement, the question shifts from "is there current public routing?" to "is the routing secure and redundant?" If the service pages consolidate under Ayaa, the question shifts from "which brand is current?" to "which platform and terms govern the customer?" If backup and VPS pages publish more detail, the question shifts from "what is claimed?" to "what has been tested?"

The best outcome for a small provider is transparent modesty. It does not need to pretend to be a hyperscale cloud. It can say exactly what it operates, what it rents, what it monitors, what it backs up, what it can restore and where the customer must still own risk. That is a better resilience story than overclaiming invisible capacity.

The conclusion: useful service claims, weak network proof

Certit Hosting Handelsbolag should be treated as a real Swedish hosting and IT-service subject with a public service history, not as a blank shell. The Certit pages describe cPanel hosting, hosted mail and collaboration, and contact details. The Ayaa pages describe a broader managed IT portfolio that includes webhosting, VPS, backup and network services from Borlange. RIPE records tie the Certit organisation to AS43021 and to IPv4 and IPv6 resources.

The same evidence also limits the claim. Current RIPEstat checks do not show AS43021 as actively announced. The announced-prefix list is empty. The neighbour view is empty. PeeringDB has no network entity for the ASN. The prefix overviews for the linked IPv4 and IPv6 resources are not currently announced in the filtered public view. RPKI validation for the two historical prefixes is unknown because no validating ROAs were found in the checked results.

That combination points to a Weak current network evidence grade. It does not say customers are down. It says public evidence does not prove live, redundant hosted capacity under Certit's own visible ASN. Any customer considering the service for production should ask where the workload runs, which network carries it, how it fails over, where backups sit, how restores are tested, who can intervene after hours and how data can be exported.

Hosted capacity is still physical capacity. For Certit Hosting Handelsbolag, the public story is most useful when it is read that way: a hosting brand, a Swedish IT-service surface, historical number resources, and a current need for direct verification of racks, transit, power, repair windows and migration paths before the service is treated as dependable infrastructure.