Episode 01: Technical Evidence Over Country of Origin — Assurance You Can Evidence

Chapters

1. 0:00The Bouncer Dilemma: Country of Origin vs Technical Proof
2. 4:35Sovereignty Through Control: The SecNumCloud Model
3. 7:37The Assurance Ladder: AL1 Operational Compliance
4. 8:37AL2a & AL2b: Auditable Controls and Trust That Travels
5. 10:50AL3 Capability & AL4 Total Transparency
6. 13:44Testing the Ladder Against EU CSA 2.0 & ENISA
7. 17:45Actionable Takeaways for CISOs & Policy Architects

Reading transcript

Automatically generated from the episode audio, with editorial paragraphing. It may contain errors and is a record of AI-generated speech, not the publication text.

1. 0:00

   So, think back to 2024. Eight and a half million systems just crashed worldwide. Right. Bringing global business to an absolute standstill. Yeah, totally. And, you know, the crazy part is the culprit wasn't some sophisticated foreign state actor. It wasn't a zero-day exploit. It was literally a routine approved software update from a trusted provider. Which is pretty terrifying when you think about it. Exactly. Yet, when governments and enterprises try to secure their networks today, their very first instinct is often to just, you know, check the passport of the supplier. Welcome to the Deep Dive, everyone.

2. 0:34

   Thanks for having me. Today, we are unpacking a really crucial working manual that recently came out of the AI Security Forum 2026. It was published by the Global Digital Foundation, and it's called Assurance You Can Evidence, a working manual for verifiable cybersecurity trust. And we should probably clarify right up front for you listening. We are analyzing this document strictly as independent analysts. You know, we didn't write it. We didn't attend the specific drafting sessions. We're just looking at the data compiled from the forum to help decode its most critical insights. Right. Exactly. And this Deep Dive is specifically for you if you're a professional cybersecurity practitioner, a CISO, an enterprise risk officer, or a policy architect.

3. 1:16

   Because the manual dives straight into this massive tension defining the industry right now. Yeah, it really does. Basically, when deciding to trust a cybersecurity product, should an organization demand verifiable, technical evidence, or do they just exclude suppliers based on where they are headquartered? Right. The country of origin debate. OK, so let's unpack this. Is cybersecurity trust kind of like a bouncer at a club checking a passport at the door, like where the country on the cover determines if you get in? Or is it an ongoing audit of how someone actually behaves once they are inside the club? Well, the manual makes a pretty hard stance here. It argues that a country of origin exclusion is really just a political policy instrument.

4. 1:57

   It's not a technical insurance one at all. Because it doesn't actually test anything, right? Exactly. It produces zero testable claims. If you ban a supplier based on their national origin, you are generating no audit trail, you have no capability assessment, and no inspection finding. Wow. So you're basically just guessing. Yeah, pretty much. And the manual highlights a really significant danger here, which is that organizations start treating the absolute absence of evidence as actual security. Oh, that's a great way to put it, the absence of evidence.

5. 2:26

   Right. When you rely on a national flag as a proxy for trust, you're almost always doing it because your organization lacks the laboratories, or the capability, or just the trained personnel to inspect the product directly. Which means checking that passport at the door completely fails when things actually go wrong in the real world. Totally fails. And the manual includes some really striking data on this, provided by an audit and legal practice at the forum, that kind of completely shifts the narrative on where threats actually originate.

6. 2:55

   Yeah, the breakdown of security, incident drivers, is super revealing. So the data shows that 70% of what actually goes wrong in cybersecurity stems from internal issues within an organization's own parameter. Wait, 70%? 70%. That's huge. And that chunk is split right down the middle. So 35% comes from technical weaknesses, and 35% comes from organizational governance gaps. Meaning only 30% of incidents are actually driven by external threats.

7. 3:25

   Exactly. Only 30%. Exactly. Exactly. If you are managing enterprise risk right now, you know the pain of this reality. I mean, the manual backs this up with the 2024 endpoint security crash we just mentioned. And also a massive 2025 content delivery network outage. Right. The CDN outage. Yeah. That 2025 event cascaded and took millions of services offline, simply because of a routine database permission change.

8. 3:48

   Literally just a permission change. Right. Neither of these catastrophic events involved an attacker. So if we had banned these top tier suppliers based on their national flag, it would not have prevented us from doing this. It would not have prevented those crashes at all. It would have had zero preventative effect. I mean, both organizations involved were highly respected top tier security providers. Yeah. One of the forum speakers actually referred to this color of the flag approach as the illusion of security.

9. 4:13

   Because it's an approach built on assumption rather than the hard, slow work of technical assessment. It's fast. And it is geopolitically convenient. Oh, definitely. But real security requires evaluating the actual mechanics of the code, and the governance structures maintaining it.

10. 4:29

    But let's look at the obvious challenge here. If origin bans don't actually secure systems from 70% of the threats out there, how do nations protect their legitimate national security and data sovereignty answers? Because those are valid concerns. Totally valid. Jurisdiction, supply chain control, the fear of foreign coercion. So how do you keep foreign coercion out of your critical infrastructure without just banning the country outright? Well, the manual points to a working model that addresses this exact problem. But through... Through technical assurance instead of blanket market exclusions.

11. 5:00

    OK. What's the model? They highlight France's SECNUM Cloud version 3.2 certification, which is currently the European Union's most demanding national cloud security scheme. And how does it work? It manages to achieve strict digital sovereignty without a single blanket country of origin exclusion. Really? None. None? None.

12. 5:20

    So it attacks the financial leverage and the operational control, not the geographic border. Precisely. Instead of a blanket ban, it uses 19 thematic domains and six core auditable pillars. OK. Give me an example. For instance, there are stripped ownership caps. Non-EU entities cannot hold more than a 24% individual stake. Oh, wow. So that means a foreign entity literally cannot execute a hostile board takeover or force strategic decisions.

13. 5:48

    Right. And then there is data sovereignty requiring all data administration and supervision to physically remain on EU soil. OK. So the data literally can't leave. Exactly. And beyond ownership, the framework demands operational autonomy. The service must be maintained either entirely by internal competencies or through at least two independent suppliers. So no single external vendor can just hold the system hostage.

14. 6:13

    Exactly. It also requires legal immunity from an extraterritorial seizure. This isolates the legal entity operating the cloud. So a foreign court cannot simply compel them to hand over European data. Because they're legally insulated. Right. These are structural, verifiable controls. So what does this all mean? It's not about locking the foreigner out of the building.

15. 6:34

    It's about making sure that whoever is in the building can only use tools we can audit. And they structurally cannot take the data out the back door. Yeah. And this concept of sovereignty through control isn't actually new. I mean, the telecommunications industry has operated this way for decades. Oh, really? Like how? Well, telecoms deal with strict national sovereignty rules regarding spectrum licenses, mandatory local presence, lawful interception capabilities.

16. 6:59

    No one considers that anti-competitive. It is just standard operating practice. Right. That's just how the industry works. Yeah. By testing the actual product against rigorous controls, you replace those assumptions with independently verified facts. Which is huge. It is.

17. 7:14

    And considering that public administration accounts for over 38% of all EU cyber incidents, governments desperately need these verifiable controls rather than just political assumptions. So if, if Secnum Cloud proves that sovereignty through control actually works in the real world, why isn't every enterprise just demanding it? Well, because until now, buyers haven't really had a standardized way to measure it. Right.

18. 7:37

    That's the gap this manual tries to close with what it calls the assurance ladder. The assurance ladder. Yeah. It's five progressive tiers designed to move the conversation from where is this from to what can you actually show me? Let's break down the mechanics of this ladder for the listener, starting right at the foundation. Okay. So the base level is AL1.

19. 7:55

    Evidence and operational compliance. Okay. Now remember that 70% of incidents are internal technical and governance failures. So AL1 is all about proving that your governance process actually runs in practice every single day. Not just on paper. Exactly. The struggle here is that most organizations treat compliance as just a paperwork exercise. One contributor in the manual emphasized that compliance cannot be confined to a PDF filed away in a drawer. It has to be a living process.

20. 8:25

    And most organizations fail at this very first level, right? Oh, absolutely. They fail right out of the gate. And if you fail there, you have zero foundation to build on. But okay, let's say you prove the engine is actually running daily.

21. 8:37

    Then you move up to AL2A, which is sovereignty through auditable controls. Right. This is where you test for the operational and legal autonomy we just talked about with the Secknam Cloud example. Okay. But the ladder splits here, doesn't it? It introduces a massive real-world hurdle called AL2B. Yeah. AL2B is what they call trust that travels. And this is where the international system often just breaks down.

22. 9:02

    Why is that? Because AL2A shows that a specific control can be audited locally. But AL2B asks if that audited control is actually recognized once it crosses a border. Ah, interoperability. Exactly. Real evidence differs from a local label in four specific ways. It must be portable, meaning it crosses borders without requiring the vendor to pay for complete retesting. Which makes sense. Which makes sense.

23. 9:25

    Retesting is expensive. Super expensive. Second, it must be verifiable, meaning the claims can be tested and disproved. Third, it must be comparable, so a buyer can assess it like-for-like across different national schemes. Okay. Portability, verifiability, comparability. What's the fourth? And fourth, it must be laboratory independent. Meaning the result holds true regardless of which certified lab actually ran the test.

24. 9:49

    Right. Because an assurance claim you can't falsify, like, you know, the country a company happened to be founded in. Isn't a real security claim. Exactly. But the manual notes that this international system of mutual trust is currently fracturing pretty badly. How so? Well, if a lab in Germany tests a product, France or Spain might not accept that certification without a unified framework. We are seeing a really severe divergence right now. Give us an example of that divergence.

25. 10:15

    So the manual points to the Common Criteria Recognition Arrangement, the CCRA. Right. It has broad international reach, but it's capped at a relatively low assurance level. The AL2. Okay. Meanwhile, you have the Voluntary European EUCC Scheme. That reaches a much higher assurance level, but it has much narrower international recognition. So they're splitting apart. Yeah.

26. 10:37

    Both are built on the same foundational ISO 15408 standard. But as they drift apart, the friction for suppliers increases massively. And the overall system of mutual trust just erodes. Which makes climbing to the next rung even more critical.

27. 10:50

    So AL3 is from compliance to capability. Right. The manual shares the perspective of a national regulator overseeing, I think, nearly 3,000 entities. And they had deadlines hitting in 2024 for risk management measures, with formal audits starting by 2026. Yeah. And the defining struggle for them wasn't figuring out if a rule existed on paper. Right. Anyone can write a rule. Exactly.

28. 11:14

    The struggle was determining whether the control was actually alive inside the organization. A control that exists only in a policy document is entirely invisible. So AL3 requires continuous testing. Yes. AL3 requires continuous technical testing, actual operational logs, and proven incident resilience. It forces organizations to basically bridge the gap between regulatory theory and operational reality. You have to prove you can take a hit and keep functioning. And then we reach the absolute top of the ladder. AL4.

29. 11:48

    Total transparency and continuous verification. The holy grail. Right. This requires an independent third party. To inspect the underlying engineering, the telemetry, and the source code itself. But, you know, we have to look at the practical reality of this. Definitely. The manual describes an evaluation center funded by the supplier, but operating entirely independently. It answers to an oversight board representing the government, the supplier, and the network operators.

30. 12:16

    It reports to the government, not the local sales office. And it cannot participate in pre-sales. Yeah. I mean, this. Sounds like an airtight security model, but it also sounds overwhelmingly expensive. Is AL4 actually scalable for you, the listener? Or is it just a luxury for the biggest players? Well, the manual is exceptionally candid about this limitation. The speaker at the forum explicitly declined to oversell AL4.

31. 12:43

    Oh, really? Yeah. They called it an entry ticket to high assurance markets. Not a guarantee of total real world security. Because, you know, threat landscapes constantly shift. Right. And regarding scalability. The manual details how this exact model failed in one particular market. And it failed entirely due to economic sustainability, not technical flaws.

32. 13:02

    Meaning the market dynamics just couldn't support the sheer cost of the lab. Precisely. The sales value for that specific supplier in that region dropped. And once the commercial volume couldn't bear the financial burden, they could no longer fund the massive, highly secure infrastructure required to protect the intellectual property at the evaluation center. Wow. Yeah. It requires a massive long-term commitment. The government has to invest heavily in continuous oversight. Network operators have to participate.

33. 13:28

    And the supplier has to maintain enough market share to pay for it all. Okay. Let me get this straight. You can spend millions of dollars reaching EAL-4. You can build this massive infrastructure, give the government total transparency into your source code, and prove your system is resilient. Yeah.

34. 13:44

    But how does this evidence-based ladder survive contact with actual European law? Ah, that is the big question. Because the manual tests this. The manual tests this framework against the proposed European Cybersecurity Act, CSA 2.0. And I should clarify for the listener right now, this manual is an enterprise risk management framework. It's not an AI-specific certification standard. Exactly. It's a broader ERM framework. Right.

35. 14:09

    But when it tests against CSA 2.0, this is where the entire system seems to just collide. It is a really severe regulatory collision. So if we look at CSA 2.0, specifically the newly proposed Title IV, which covers... ICT supply chain security, a totally different approach emerges. Okay. What does Title IV do? It introduces a supplier risk route. Under this draft law, if the European Commission formally designates a country as posing cybersecurity concerns, suppliers from that country become defined as high risk by law. Just by the flag?

36. 14:43

    Just by the flag. And the direct consequence is that they are legally excluded from EU certification, public procurement for key assets, and EU funding. So wait. You could achieve AL-4? Prove your code is flawless in an independent lab, but if a new geopolitical law passes tomorrow, designating your headquarters country as high risk, you are banned anyway. Yep, you're out. That makes the entire multi-million dollar assurance ladder feel completely useless. How does the manual assess this from a strictly technical perspective? Maintaining strict neutrality here, the technical critique in the manual is highly precise.

37. 15:18

    They point out that this legal exclusion operates on a completely different axis than the assurance ladder. How so? Well, a country of origin designation produces no AL-1 evidence that daily governance is running. It produces no AL-2 independent test results against specific operational controls. Right. It offers no AL-3 assessment of organizational resilience and zero AL-4 inspection of the underlying engineering. It is not a higher rung on the ladder. It bypasses the ladder entirely. Wow.

38. 15:47

    And the manual argues this contradiction creates a dangerous loop, right? Yeah. Because if governments just use a legal pen to ban origins, it pulls investment and attention away from building actual testing and inspection laboratories. Exactly. Yeah. Which is incredibly ironic because the lack of those testing capabilities is exactly what makes governments feel they must rely on an origin ban in the first place. That's a huge catch-22. It really is. It starves the technical assurance ecosystem of funding.

39. 16:16

    And this friction is happening within a massive interlocking web of European regulations right now. Like what? Well, you have NIS2, which dictates strict legal obligations for organizational risk management and forces companies to report breaches within a 24-hour clock. Right. At the same time, you have the Cyber Resilience Act, or CRA, dictating the technical security standards for the products themselves. Then you have DORA for the financial sector and the CSA framework for certification. So the friction happens because these legal reporting clocks and product engineering standards don't perfectly align. They don't align at all. The manual briefly touches on the European Union Agency for Cybersecurity, INISA, which kind of acts as the strategic glue trying to hold this framework together, right?

40. 17:03

    Yeah. They host the certification framework, support the NIS2 reporting networks, provide technical expertise for the CRA, and develop schemes like EUCC. So they have their hands full. Extremely. They are trying to make evidence-based trust function across borders, but they are doing it without clear architectural alignment from the policy makers. And the architectural problems are significant. For example, once the CRA product standards become fully applicable, practitioners really do not know how existing national certification schemes will overlap with it. Right. Will they be forced to revise, align, or replace each other?

41. 17:41

    Enterprise risk officers are currently forced to navigate this regulatory friction in real time. Which means we need to talk about actionable takeaways. Absolutely. We don't want to leave you, the listener, with just a theoretical framework and a list of regulatory concepts. Contradictions. So the manual distills specific tech steps based on the convergence of six different expert panelists at the forum. Let's break down what practitioners and policy makers should actually do to navigate this. Okay. First up, the directive for policy makers and regulators is to just be intellectually honest. Always a good start.

42. 18:14

    Right. If you are adopting an origin-based instrument, be explicit about what testable security property it establishes that technical controls do not. Meaning? Don't pretend it's a technical test if it's a political one. If the real answer is that you simply lack the laboratories and inspection capability to test the product, admit that it is a capability gap. Fund the development of that capability rather than papering over the gap with a legal designation. That makes total sense. And for the procurement teams and enterprise buyers out there, stop accepting policy PDFs as proof of security. Yes.

43. 18:50

    Please stop. You have to demand. Operational records. Mm-hmm. Ask the vendor for incident logs, configuration management records, and test results from independent third-party labs. Ask them to prove their claims at a stated assurance level rather than just handing over a rubber stamp certificate. And finally, for the vendors and suppliers listening, you must get your house in order. The manual notes that manufacturers frequently cannot even fully document their own products. Like with SBOMs.

44. 19:21

    Exactly. A primary example is the Software Bill of Materials, or SBOM, the comprehensive inventory of all the software components and dependencies inside your product. If you struggle with the basic engineering discipline required to maintain an accurate SBOM, you won't even reach AL-1 or AL-2 on the assurance ladder. Because you can only publish and certify what can be independently verified. Right. Process matters infinitely more than paperwork. Technical capability has to be built and tested, not just assumed based on a flyer. We've covered a tremendous amount of ground today, unpacking the collision between technical assurance and political policy. We really have.

45. 20:00

    But I want to leave you with one final provocative thought based on a glimpse into the future mentioned in the manual. Okay. Let's hear it. So we talked about how AL4, total transparency and deep code inspection, is overwhelmingly expensive and hard to scale, right? Yeah. To the point of market failure. Right. But what if artificial intelligence could codify that event? What if AI could scale the deep inspection of millions of lines of source code in a fraction of the time and cost? Oh, wow. If AI eventually makes top-tier, verifiable, technical trust affordable for every enterprise, doesn't the entire country of origin debate become completely obsolete?

46. 20:42

    I mean, if the bouncer at the club suddenly has x-ray vision and a real-time behavioral feed for every single person in the room, why would they ever need to look at the passport? That is a really profound hypothesis. I mean, if technology outpaces the cost barrier of technical assurance, the reliance on geopolitical proxies for trust will face a massive reckoning in the coming years. Something for all of us to mull over as the regulatory landscape shifts. Thank you for joining us on this deep dive. We highly encourage you to take this assurance ladder, look at your own enterprise risk strategies, and start asking for the evidence. We'll see you next time.