
TL;DR: TRUE's data sits in Sweden, with a Swedish company under Swedish law. The server address is still only half the answer, because the US CLOUD Act follows ownership rather than geography: a vendor with a US parent is covered even when the hardware stands in Frankfurt. Sweden's first cloud policy, adopted in May 2026, rests on the same point. Below is what Swedish hosting means for digital credentials, what the Swedish cybersecurity act demands of your supply chain, and the five questions that decide whether a credential is still verifiable in ten years.
Swedish hosting means the credentials, the personal data and the backups are stored and processed on servers in Sweden, by a company under Swedish law. Digital credentials add a constraint ordinary web services do not have. The credential must remain checkable long after it was issued, often ten or twenty years later, so where it lives is an archival decision rather than an operational one.
A course certificate differs from a customer database on the one point that decides everything. The database is used today and emptied when it goes stale. The certificate is used the day the holder applies for the job, and that day can be seven years out.
Whoever buys the system is rarely the person who needs the proof. The head of training runs the procurement. The participant holds the certificate much later, usually in front of an employer who has never heard of the vendor. Between those two points the vendor has time to change owner, move its operations or shut down.
The US CLOUD Act lets US authorities compel data from US companies regardless of where the server physically sits. The law follows ownership, not geography. A European region operated by a US-owned vendor moves the hardware and leaves the jurisdiction untouched.
The Court of Justice of the European Union invalidated Privacy Shield in July 2020, in the ruling known as Schrems II. Transfers to US vendors have since required supplementary measures and an assessment of the recipient country's law. An Irish subsidiary does not settle the question, because the US parent can still be ordered to produce the data.
Credly is the easiest example to check, because it turns up in nearly every procurement we see. Pearson acquired the company in 2022 for 200 million dollars, and the parent, NCS Pearson, sits in Hoboken, New Jersey. Credly's own privacy policy states that personal data may be processed outside the EEA, including in the United States. The servers can stand anywhere. The ownership chain ends in US jurisdiction. We compared the two platforms point by point in TRUE and Credly side by side.
In May 2026 the Swedish government adopted Sweden's first cloud policy for public administration. The policy is meant to strengthen security, reduce dependencies and give better control over data, and one of its sections is titled Principles for strengthened digital sovereignty and reduced lock-in. The Swedish Post and Telecom Authority was tasked with supporting the rollout.
Erik Slottner, Minister for Public Administration, gave the reason when the policy was presented on 28 May 2026. His words, in Swedish: ”Samtidigt behöver vi stärka vårt digitala självbestämmande och minska risken för att bli beroende av enskilda leverantörer.” Sweden needs to strengthen its digital self-determination, in other words, and reduce the risk of becoming dependent on individual vendors. The decision is published by the Swedish Government Offices.
The policy addresses public authorities, municipalities and regions. Its reach runs further. A university procuring a credential platform, a trade body certifying against a standard and a training company selling into the public sector all meet the same questions on the same form: where does the data sit, who owns the operation, what happens if you disappear.
The Swedish National Agency for Public Procurement has been asked outright whether a buyer may require that information be stored only in Sweden or within the EEA. The answer depends on the type of information. Personal data falls under GDPR, information bearing on national security under the Protective Security Act (2018:585). For most credential issuers GDPR is the relevant regime, and there a requirement to store inside the EU has moved from exception to standard.
The Swedish cybersecurity act (2025:1506) entered into force on 15 January 2026 and implements NIS2 in Swedish law. It covers an estimated 8,000 organisations across 18 sectors, and one of its largest changes is the requirement to secure the whole supply chain. Entities in scope must impose cybersecurity requirements on their suppliers and be able to show that they did.
The reach goes past those 8,000. A training company selling to a region, a public authority or a large industrial group inherits the requirements through its customer, even though the act does not point at its own operation. The customer must be able to account for where the supplier's data sits, which sub-processors have access and how incidents get reported. An answer that ends in "our supplier's supplier" is not an answer.
Five questions separate a vendor that survives a review from one that merely sounds right. They cover storage location, ownership chain, which domain the proof lives on, what happens when the contract ends, and whether the credential can be verified without the vendor.
A platform where verification is a lookup against the vendor's database is a platform where the proof dies with the company. Digg describes the same principle in its framework for credential handling: a verifiable credential is checked through its digital signature, which shows that the credential is genuine and has not been altered.
Data storage is a location. Data sovereignty is a question of who can compel the data, who can lock you in and who is in a position to refuse a request. Two vendors can store at the same address in the same city and still answer those three questions very differently.
Sweden's cloud policy places lock-in next to security, and that is deliberate. Supplier switching, open standards, clear contracts and an exit plan appear as points of their own, singled out as especially important during crises such as serious geopolitical events or cyber incidents. A vendor you cannot leave is a risk even when nobody is compelling anything.
For credentials the lock-in takes a form that is easy to miss. If the proof lives on the vendor's domain, the address leaves with the vendor. Change systems and every previously issued credential stops working, and those credentials already sit in recipients' inboxes, on their LinkedIn profiles and inside applications that have been submitted.
A usable requirement covers three things that cannot be collapsed into one: where the data is stored, which jurisdiction the vendor and its ownership chain answer to, and whether the proof can be checked independently of the vendor. A requirement that names only a storage location lets through a US-owned vendor with an EU region.
Digg, the Swedish Agency for Digital Government, publishes ready-made requirement texts for procuring IT systems and digital services, and they make a better starting point than wording supplied by a vendor. Keep in mind too that a requirement naming a specific standard needs to be followed by the words or equivalent, and that the evidence demanded has to stay proportionate to what is being protected.
The third part, independent verification, is the one most often missing altogether. It decides what the issued credentials are worth once the contract period ends, and that is a longer horizon than any other requirement in the tender.
TRUE runs on Swedish hosting. TRUE Original is a Swedish limited company registered in Stockholm with no parent company in a third country, so there is no ownership chain that can be compelled to hand over data under foreign law.
Karolinska Institutet, Bolagsverket and the Swedish Theft Prevention Association all filled in the same boxes about data storage and vendor dependency before they became customers. How we work with encryption, access control and incident handling is set out in our account of data security and interoperability.
The credentials also live on the customer's own domain. A credential from a university sits at the university's address, not at ours. Sharing drives traffic to the issuer, and verification happens at an address the recipient recognises.
Every credential receives a cryptographic fingerprint anchored on a public blockchain at the moment it is issued. Anyone holding the document can check that fingerprint on TRUE Verify without an account and without a fee. Verification works even if the company is gone.
Swedish hosting protects the data while the service is alive. The anchor protects the proof afterwards. How that squares with the right to be forgotten is covered in blockchain and GDPR.
The question of where data is stored is answered with the name of a country. The question of what the credential is worth the day the vendor goes bankrupt is answered with technology, and that question now appears on the same form.
The participant who opens her credential in 2036 knows nothing about the cloud policy, the ownership chain or which data centre was named in the contract. She clicks the link and sees whether the proof holds.