5 questions that reveal whether your digital sovereignty is real

Ask any systems manager where their data is hosted, and they’ll tell you without hesitation. Ask them who can access those systems right now, with what privileges, and for how long, and they’ll likely start to hesitate.

For the past few years we’ve tied digital sovereignty to a single question: where is our data?

It’s not the wrong question, but it’s no longer the right one.

Because an organization can host its entire infrastructure in Europe and still have no idea who is entering its critical systems right now.

Most articles on this topic stop at the first questions: where the data is, under what jurisdiction, whether the vendor is European or not. It’s a legitimate discussion, but an incomplete one. A company can have its entire infrastructure on national soil and still have no idea who logged into the production server last night, what they did, or whether it could revoke their access right now without calling the vendor. That’s not sovereignty. That’s geography dressed up as control.

This article proposes something different: a way to measure real control with 5 key questions.

The digital sovereignty test

Instead of a new definition, we’ll ask five questions. If your organization can’t answer them with confidence, it doesn’t matter where its servers are — it doesn’t have sovereignty over its critical systems.

1. Can you revoke any user’s or external vendor’s access in under 5 minutes, without relying on a third party’s support?

If the answer involves opening a ticket and waiting, the control isn’t yours.

2. Do you know exactly what each privileged user did the last time they accessed the system?

An access log tells you who logged in. It doesn’t tell you what systems they manipulated. That difference separates a real audit from a box ticked for compliance.

3. Could you isolate a compromised session right now without shutting down the entire system?

Most organizations only have two options when facing a suspicious session: let it continue or disconnect everything. Neither is control.

4. Could you prove in an audit, with your own data and without having to ask the vendor, who accessed which critical system over the past twelve months?

If traceability lives on someone else’s platform, so does sovereignty.

5. Does that visibility also cover your OT systems, or only traditional IT?

Many organizations consider access control in the office solved and have never asked themselves the same question about their plants.

If the answer is “no” or “it depends” to any of these questions, the problem is architectural, not a matter of where the data sits.

The conversation is happening in the wrong place

For the past few years, the debate on digital sovereignty has revolved almost exclusively around one question: where is the data, and under what jurisdiction?

And it’s not a minor concern. The U.S. Cloud Act allows American authorities to request information from technology vendors subject to their jurisdiction, even when that data is physically stored outside the country. For defense organizations, public administrations, critical operators, or financial entities, this capability introduces a legal and strategic risk that can’t be ignored.

However, centering the entire conversation on jurisdiction leads to a false sense of control.

Jurisdiction determines who can request access to information. But it doesn’t determine who is actually accessing the systems at this precise moment, what privileges they hold, what actions they carry out, or how long it will take the organization to detect it if something goes wrong.

Key idea: Jurisdiction determines who can request access. Operational control determines who can actually access.

In other words, legal sovereignty doesn’t imply operational governance of access. And it’s precisely that second dimension — control over identities, privileged access, and sessions — that decides whether an organization retains effective control over its infrastructure or simply trusts that everything will work as it should.

The difference seems subtle, but its consequences are enormous.

CrowdStrike proved something unexpected

On July 19, 2024, a faulty update distributed by a single cybersecurity vendor left around 8.5 million Windows machines inoperative worldwide. Airlines, hospitals, banks, public administrations, and critical infrastructure operators all suffered simultaneous outages.

It wasn’t a sophisticated attack. There was no security breach.

It didn’t expose a security flaw. It exposed a dependency.

Millions of organizations discovered that a single update could halt their global operations. That day changed the conversation about resilience.

When an organization fully delegates the ability to control who accesses its critical assets, it is also outsourcing part of its operational resilience.

Digital sovereignty begins long before deciding where data is stored. It begins when the organization retains the ability to govern its identities, its privileges, and its access, regardless of the technology vendor it uses.

Regulation doesn’t ask where the data is; it asks who controls the access

This shift isn’t an interpretation. It becomes very clear when you look at what Europe’s main cybersecurity and resilience regulations actually require — all of them with explicit demands around privileged access management and identity control.

Regulatory framework	Specific requirements on access
NIS2 (Directive (EU) 2022/2555)	Requires implementing identity management and access control policies as a baseline cybersecurity measure. Mandates limiting privileges, securely managing credentials, controlling access to critical systems, and being able to demonstrate that only authorized users access essential assets.
DORA (Regulation (EU) 2022/2554)	Requires financial entities to establish robust controls over privileged access, periodically review permissions, apply the principle of least privilege, and oversee the access of employees, third parties, and ICT providers throughout the entire lifecycle of the relationship.
Cyber Resilience Act (Regulation (EU) 2024/2847)	Requires digital products to incorporate secure authentication mechanisms, access control, and protection against unauthorized access from the design stage (security by design), reducing the exposure of privileged interfaces and functions throughout the product’s lifecycle.
Esquema Nacional de Seguridad (Royal Decree 311/2022)	Establishes mandatory measures for identification, authentication, authorization, and access control based on the system’s category. Requires traceability of actions, segregation of duties, privileged account management, and event logging to ensure access auditability.

The common denominator is clear. None of these regulations considers it sufficient to state that data stays in Europe or that the vendor is European.

What they require is something much harder to demonstrate:

• Who can access
• Who is actually accessing
• With what privileges
• For how long
• Under what controls
• With what capacity for audit and response to any incident

In short, regulation is evolving from information sovereignty toward real governance of access.

The five maturity levels of digital sovereignty

Digital sovereignty isn’t a binary state. It isn’t achieved simply because data resides on national soil or because the vendor is European. It’s a maturity process that reflects the degree of effective control an organization exercises over its critical assets.

The difference between one level and the next isn’t the amount of technology deployed, but the capacity to govern identities, control privileged access, reduce dependency on third parties, and retain decision-making capacity even in crisis situations.

In other words, the higher the maturity level, the smaller the gap between regulatory compliance and real operational control.

Level	Maturity	Organizational capabilities	Key question
Level 1	Dependency	Access is managed through basic procedures and administrative controls. Shared accounts, permanent permissions, limited traceability, and heavy reliance on vendors or manual processes exist. Compliance is demonstrated mainly during audits.	Do you actually know who can access your systems?
Level 2	Governance	The organization has identity policies, multi-factor authentication, onboarding/offboarding procedures, and periodic permission reviews. A governance framework exists, but much of the control remains administrative and reactive.	Do you have clear rules for deciding who can access?
Level 3	Visibility	Access, identities, and sessions are monitored. Centralized logs, an inventory of privileged accounts, and the ability to detect anomalous behavior exist. However, response still partly depends on external tools or third-party intervention.	Do you know who is accessing your systems right now?
Level 4	Control	The organization actively controls access through dynamic privileges, Just-in-Time (JIT) access, session recording, segregation of duties, and immediate permission revocation. It can contain incidents without fully depending on the technology vendor.	Can you limit or revoke any access immediately when the situation requires it?
Level 5	Operational sovereignty	Identity, authentication, authorization, and privilege management are part of a strategic architecture under the organization’s direct control. Even if a vendor becomes unavailable, is replaced, or is compromised, the organization retains the ability to decide who accesses what, when, how, and under what conditions.	Would you retain control of your critical assets even if one of your technology vendors disappeared tomorrow?

From compliance to control

Many organizations believe they’ve reached a high level of maturity because they comply with the main regulatory frameworks, apply multi-factor authentication, or have identity management solutions in place.

However, when you examine their ability to govern privileged access, revoke permissions in real time, control critical sessions, or maintain operations during a technology vendor outage, the reality is usually different.

In practice, a significant part of the market still operates between levels 1 and 2. Some organizations have reached level 3, incorporating monitoring and traceability capabilities, but few have evolved toward a fully operational control model.

Reaching levels 4 and 5 is no longer just about deploying new tools. It requires an architectural shift: moving from trusting that access is protected to actively governing it, reducing technological dependency, and retaining decision-making capacity under any circumstances.

That is precisely the point where digital sovereignty stops being a legal question and becomes a strategic capability. Because an organization only exercises real control when it can maintain effective governance over its identities, its privileges, and its access — regardless of the vendor, the technology used, or the geopolitical context it operates in.

How does this translate in practice?

Controlling access doesn’t mean having a strong password policy or a second authentication factor. It means being able to observe, isolate, and cut off an active session without that depending on the goodwill or availability of a third party.

That’s exactly the problem solved by the Remote Shielded Workspace (RSW) model applied by Endurance, Cosmikal’s solution: a Zero Trust environment that protects IT and OT assets without exposing them or depending on endpoint security, with full traceability and real-time session video recording capability. The session is cut immediately if something doesn’t add up, with no need to shut down the system or wait for the external vendor to cooperate.

This isn’t a layer added on top of separate PAM (Privileged Access Management), IAM, or VDI tools. It’s integrating them into a single point of control, which avoids the most common problem: identity managed in one tool, remote access in another, and traceability in a third, with none of the three having full visibility into what a privileged user does from start to finish.

What digital sovereignty means, sector by sector

The test is the same, but what’s at stake changes depending on the sector:

• Public administration: complying with ENS isn’t optional, and product certification against CCN is increasingly a procurement requirement.
• Defense: interoperability with allied standards (such as NATO’s NIAPC catalogue) determines which solutions can be used on which projects.
• Banking and insurance: DORA turns ICT third-party risk management into an auditable obligation, not a best practice.
• Energy, water and infrastructure, industry: the question about OT is as relevant as the one about IT (and often more urgent): the impact of an uncontrolled session isn’t a data leak, it’s a plant shutdown.
• Healthcare: traceability of who accessed which system is both a data protection requirement and a patient safety matter.
• Telecommunications: as critical infrastructure operators under NIS2, they’re among the first required to demonstrate access control, not just declare it.

Endurance as a reference case

Endurance was the first Spanish solution to obtain LINCE certification from the Centro Criptológico Nacional (CCN) in the Privileged Access Management (PAM) taxonomy within the Catálogo de Productos y Servicios STIC (CPSTIC). Extending that same certification to the VDI taxonomy is in its final phase, with completion expected in the coming weeks. This dual presence in the catalogue, across two distinct taxonomies, is to date unprecedented in the Spanish market.

In June 2026, Endurance was also added to the NATO Information Assurance Product Catalogue (NIAPC), as the first Spanish solution in the Access Control category — a validation process that requires evaluation by a national certification authority recognized by the Alliance, in this case CCN itself.

None of these certifications replace this article’s five-question test. What they do is something different and more valuable: they allow an independent third party (not the manufacturer itself) to confirm that the answers to that test are objectively true, not just a product claim.

The final answer

Digital sovereignty isn’t demonstrated with a map of data centers. It’s demonstrated by answering, without hesitation, this article’s five questions, and, where the sector requires it, by being able to prove it to an independent body.

Digital sovereignty doesn’t begin when you decide where to store your data.

It begins when you can decide, at any moment, who enters your systems, what they can do, and when they stop being able to do it.

Frequently asked questions

What’s the difference between digital sovereignty and technological independence?

Technological independence seeks to reduce dependency on a specific vendor or manufacturer. Digital sovereignty additionally requires being able to demonstrate, at any moment, who controls access to critical systems, regardless of who manufactures them or where they’re hosted.

Is it possible to have digital sovereignty while using cloud services or non-European vendors?

Yes, as long as the organization retains control over identities, keys, and the ability to revoke and audit access without depending on the vendor to do so.

What role does PAM play in digital sovereignty?

Along with identity management (IAM), it’s the most direct mechanism for exercising that control: it decides who can access a critical system, with what privileges, for how long, and with what traceability. Robust privileged session control is, in practice, the operational muscle of digital sovereignty.

What relationship exists between Zero Trust and digital sovereignty?

Zero Trust provides the principle — not trusting by default any user, device, or session — but digital sovereignty additionally requires that distrust to translate into a real capacity for revocation, isolation, and auditing, managed by the organization itself and not fully delegated to the vendor.

Can an organization comply with NIS2 and still lack digital sovereignty?

Yes. Complying with NIS2 demonstrates that documented policies and controls on identities and access exist, but it doesn’t guarantee that the organization can exercise that control immediately and autonomously in the event of an incident. Regulatory compliance is the floor, not the ceiling, of operational control.

How does Cosmikal help with certifications and audits (ENS, NIS2, DORA)?

Endurance is LINCE-certified by CCN in PAM (with the extension to VDI in its final phase) and included in NATO’s NIAPC catalogue, which makes it easier to demonstrate to auditors and procurement bodies compliance with the access control requirements demanded by ENS, NIS2, and, in the financial sector, DORA.

Sources

[1] CLOUD Act (2018) — U.S. Department of Justice. https://www.justice.gov/criminal/cloud-act-resources

[2] Global CrowdStrike incident, July 19, 2024 — IBM. https://www.ibm.com/think/news/recent-crowdstrike-outage-what-you-should-know

[3] Endurance: Remote Shielded Workspace (RSW) — Cosmikal. https://www.cosmikal.es/soluciones/cosmikal-endurance/

[4] Cosmikal obtains LINCE certification from CCN for Endurance (PAM) — Cosmikal. https://www.cosmikal.es/cosmikal-obtiene-certificacion-lince-centro-criptologico-nacional-producto-endurance/

[5] ENS, LINCE, CPSTIC, and Common Criteria: what they are and how they differ — Cosmikal. https://www.cosmikal.es/ens-lince-cpstic-y-common-criteria-que-son-y-en-que-se-diferencian/

[6] Cosmikal’s Endurance joins NATO’s NIAPC catalogue — Cosmikal. https://www.cosmikal.es/endurance-de-cosmikal-se-incorpora-al-catalogo-niapc-de-la-otan-como-primera-solucion-espanola-en-control-de-accesos/

[NIS2] Directive (EU) 2022/2555 — Centro Criptológico Nacional (CCN). https://www.ccn.cni.es/es/normativa/directiva-nis2

[DORA] Regulation (EU) 2022/2554 — EUR-Lex, Official Journal of the EU. https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32022R2554

[CRA] Regulation (EU) 2024/2847 — EUR-Lex, Official Journal of the EU. https://eur-lex.europa.eu/eli/reg/2024/2847/oj

[ENS] Royal Decree 311/2022, Esquema Nacional de Seguridad — Boletín Oficial del Estado (BOE). https://www.boe.es/buscar/act.php?id=BOE-A-2022-7191