DarkSword and Zero Trust Reckoning

 Threat Intelligence & Mobile Security

DarkSword and the Zero Trust Reckoning

The Collapse of iOS Inviolability — and Why Software Hygiene Is Now a Survival Metric for Institutions

For the better part of a decade, the default posture of any IT leader recommending a mobile device strategy was predictable: hand the executive an iPhone and call it a day. The logic was almost bulletproof. Apple's vertically integrated stack — hardware, OS, and App Store gatekeeping — gave the walled garden metaphor genuine teeth. While Android's fragmented patch ecosystem left enterprise security teams running perpetual triage, iOS was the closer-to-settled question.

I've used that framing in vendor conversations. I've built a mobile policy around it. And now, with the emergence of DarkSword, I find myself revisiting every assumption underneath it.

This is not alarmism. This is what the intelligence looks like from the ground — and what it demands of leaders who sit at the intersection of institutional trust and operational technology.

⚠ Threat Classification

DarkSword is a sophisticated zero-click exploitation framework documented by Google's Threat Analysis Group (TAG), Lookout, and iVerify. It operates via watering-hole attacks — compromised legitimate-looking web properties — to achieve remote code execution (RCE) through the WebKit engine without any intentional user interaction. It does not require a malicious app download. It does not require clicking a phishing link. It requires only that a device browse to an infected site. [See TAG advisory and corresponding CVE disclosures for technical attribution]

---

The Architecture of Compromise

What distinguishes DarkSword from the commodity malware cluttering most threat briefings is architectural intentionality. This toolkit was not built to linger. It was built for surgical, deniable exfiltration — a design philosophy more consistent with state-sponsored tradecraft than with the opportunistic criminal ecosystem.

The exploit chain targets WebKit — the rendering engine that powers every browser on iOS without exception, a direct consequence of Apple's platform policy requiring all third-party browsers to use WebKit. By exploiting a series of memory-corruption vulnerabilities in the WebKit JIT compiler, DarkSword achieves privileged code execution, escapes the application sandbox, and moves laterally into core system processes. From that position, the data exposure is comprehensive:

iCloud Authentication Tokens

Token capture enables access to cloud backups without triggering standard 2FA workflows. This is not a brute-force attack — it is a session hijack that appears to be a legitimate authenticated session from Apple's perspective.

End-to-End Encrypted Message Content

Encryption protects data in transit. DarkSword accesses data at the endpoint — after decryption — rendering transport-layer security architecturally irrelevant to this attack vector. iMessage, Signal, WhatsApp: the message content is readable at the device layer before any encryption is applied or after it is removed.

Keychain Access

For institutional users, this is the catastrophic tier. Corporate SSO credentials, VPN certificates, privileged access tokens, and — for any cryptocurrency-adjacent users — private keys. A compromised Keychain is a compromised identity, potentially enterprise-wide.

The initial geographic targeting — Saudi Arabia, Turkey, Malaysia, and Ukraine — is consistent with intelligence-service interest patterns. But that window has closed. The toolkit has surfaced on GitHub. We have entered what I would call the democratization phase of cyber-espionage: sophisticated zero-day weaponry, previously accessible only to nation-state actors with eight-figure operational budgets, is now available to script-tier threat actors and regional criminal cartels.

This is the threat multiplier that should concern every institutional technology leader. The original adversary was disciplined and selective. The downstream actors running forked GitHub deployments will not be.

---

The One-Fifth Vulnerability Gap

Apple has moved with unusual speed. Patches were issued in iOS 26.3 and the subsequent iOS 26.3.1(a), specifically addressing the WebKit JIT vulnerabilities in the exploit chain. Rapid Security Response (RSR) patches were also pushed for select configurations. From a vendor posture standpoint, Apple's response was close to the industry ceiling of what we can reasonably ask for.

~20%of the iOS install base is still running unpatched versions —
trailing iOS 18.4 through 18.7 — as of current estimates

That gap is not a technology failure. It is a human-systems failure — and, in an institutional context, a governance failure.

Consider what that 20% means in practice. Automated vulnerability scanners — the same category of tool that pen testers use — can identify unpatched WebKit targets at scale. A device running iOS 18.x does not need to be specifically targeted; it simply needs to be found. In a world of exploit automation, being three minor versions behind is not a risk posture — it is an open enrollment in the breach pipeline.

---

The Hardened Institutional Posture

The following is not a "best practices" checklist. It is the minimum viable defensive architecture for any leader responsible for sensitive institutional data — financial records, student information, executive communications, privileged credentials. The bar has moved. Adjust accordingly.

1

Eliminate the Update Lag — Immediately and Institutionally

The 48-to-72-hour window between patch release and device update is the primary operational window that exploit actors bank on. On the individual level, enable:

Settings → General → Software Update → Automatic Updates

Toggle both "iOS Updates" and "Security Responses & System Files" to ON. The latter enables Apple's Rapid Security Response mechanism, which pushes critical patches outside the standard update cycle.

On the institutional level: if your MDM (Jamf, Intune, Kandji) does not have an enforced OS version policy with an update compliance threshold, that gap needs to close in your next governance cycle — not next quarter. Define an acceptable lag window (72 hours for critical patches is a defensible standard) and enforce it through device enrollment policy.

2

Deploy Lockdown Mode for High-Risk Personnel and Environments

Standard iOS hardening is insufficient for DarkSword-class threats because the attack surface — WebKit JIT compilation — is not addressable through configuration alone. Apple's Lockdown Mode structurally disables the JIT compiler pathways and reduces the JavaScript attack surface upon which the exploit chain depends.

Settings → Privacy & Security → Lockdown Mode

Lockdown Mode carries real usability tradeoffs: certain web technologies are disabled, some file attachments won't open, and complex web apps degrade in performance. This is not a fleet-wide recommendation. It is the appropriate posture for executives, finance personnel, IT administrators, and anyone who regularly accesses privileged systems from mobile devices — particularly when traveling or connecting outside your perimeter controls.

3

Treat Mobile Browsing as a Hostile Environment

DarkSword's use of watering hole attacks — lookalike portals impersonating government contractor sites, enterprise SaaS login pages, and consumer tools like Snapchat — challenges the comfortable assumption that users can identify unsafe sites by appearance or reputation. DarkSword doesn't need you to download a file. It just needs you to view a page. That single fact should reframe how your entire organization thinks about mobile browsing.

The smishing vector deserves specific attention. A well-crafted SMS instructing a user to "verify your account" at what appears to be a legitimate government portal or enterprise login page is all DarkSword needs as a delivery mechanism. Train your users on one absolute rule: if a link arrives via SMS, social media DM, or personal email and it asks you to log into anything, do not click it. Type the address manually into the browser or navigate through a trusted password manager that provides domain verification.

On the institutional side, sensitive web navigation should happen through corporate-managed browser profiles with DNS filtering and Safe Browsing enforcement active. On mobile, this discipline is harder to enforce than on managed desktops, which is precisely why it must be a trained behavior and a user awareness priority — not an assumed one.

4

Treat Hardware Deprecation as a Security Policy Decision

This is the conversation institutional technology leaders consistently defer because it carries budget implications. DarkSword forces the issue. Devices that cannot run iOS 26 do not have access to the hardware-level exploit mitigations built into recent A-series silicon — specifically, Pointer Authentication Codes (PAC) and the memory-tagging improvements in more recent SoC generations that make modern exploits structurally harder to write.

To be concrete: an iPhone 8, iPhone X, or anything older cannot run the security architecture required to resist this class of exploit. These devices are not merely feature-limited — they are mathematically easier to exploit. The cryptographic and memory-isolation primitives simply aren't present in the hardware. An iPhone maxing out at iOS 15 or 16 is not a legacy device. It is a structurally undefendable endpoint.

If your organization has device refresh policies that allow five-plus-year-old mobile hardware to access institutional systems, that policy is now a liability exposure, not a cost-saving measure. Frame it that way in your next budget conversation.

5

Conduct an Emergency Institutional Audit — Today

This is the step most organizations skip, and the one with the most immediate risk-reduction value. Through your MDM console, pull a current OS version compliance report for every enrolled mobile device. Identify every device running iOS 18.x or earlier. Flag them. Communicate directly with those users. Do not wait for the next scheduled IT communication cycle.

If your mobile fleet is partially or entirely unmanaged — BYOD with no MDM enrollment — you need to initiate a more fundamental governance conversation. Start by quantifying the exposure you currently cannot see.

6

Monitor for Enclave Anomalies — Know the Behavioral Signatures

DarkSword is engineered to be stealthy — it does not announce itself with popup alerts or obvious system crashes. But even surgical exfiltration leaves traces. Active data transmission is power-intensive, and exfiltration operations that run while a device is idle create observable behavioral artifacts. Knowing what to look for is part of a mature defensive posture.

Train your security-aware users — and particularly your high-risk personnel — to treat the following as potential indicators of a compromised environment that warrant immediate device isolation and incident response:

• Unexplained battery drain or device overheating while idle. Background exfiltration consumes CPU and radio resources. A device that runs warm or drains noticeably faster when not in active use is worth investigating.
• Unsolicited prompts for iCloud password or Keychain access. A legitimate app or OS update will not ask for Keychain credentials out of context. An unexpected prompt — especially one that appears unprompted while browsing — should be treated as hostile.
• Unknown profiles in Settings → General → VPN & Device Management. This is the first place to look on any suspected device. A configuration profile installed without user knowledge is a reliable indicator of device compromise. Check this regularly on any device handling sensitive institutional data.

If any combination of the above appears, the correct response is not to dismiss it and monitor further — it is to remove the device from institutional network access, escalate to your security team, and treat it as a confirmed incident until forensic analysis says otherwise.

DarkSword is not a singular event to be patched and forgotten. It is a leading indicator of a structural shift in the mobile threat landscape — one that has been visible to security researchers for years and is now arriving as operational reality for institutional technology leaders.

The Zero Trust architecture principle — never trust, always verify, assume breach — was designed for exactly this threat profile. We have applied it reasonably well to network perimeters and identity management. We have applied it inadequately to mobile endpoints, largely because the "walled garden" narrative gave us permission to treat iOS as a trusted device by default.

That permission has been revoked.

Apple will continue writing patches. The adversary ecosystem will continue developing exploit chains. The variable that determines institutional outcomes in that arms race is not vendor response time — it is the culture of security discipline you build inside your organization. Update cycles enforced. Hardware policies rationalized. User behavior is shaped by training that reflects actual threat patterns rather than the last decade's phishing examples.

The 20% who aren't updating aren't negligent. They are people operating in an environment where security discipline has not been made structurally easy, institutionally expected, or consequently enforced. That is a leadership problem. Which means it is, for those of us in technology leadership roles, our problem to solve.

Don't be the institution that finds out, the hard way, that it was in the vulnerable 20%.

---

Quick-Reference: DarkSword Defense Checklist

• Enable Automatic Updates, including Security Responses & System Files
• Enable Lockdown Mode for executives, admins, and finance personnel
• Never click login links from SMS, DMs, or personal email — type URLs manually
• If on an iPhone 8, X, or older — plan an immediate hardware upgrade
• Pull MDM compliance report; flag and contact all iOS 18.x or earlier devices
• Audit Settings → General → VPN & Device Management for unknown profiles
• Report idle overheating, battery drain, or unexpected Keychain prompts to IT immediately

---

Source Note: The DarkSword threat intelligence referenced in this article is attributed to Google's Threat Analysis Group (TAG), Lookout, and iVerify. Readers in institutional security roles are encouraged to refer directly to the original CVE disclosures and TAG advisory documents for full technical attribution. As with all active threat intelligence, the landscape evolves rapidly — verify current patch status against Apple's official security release notes at support.apple.com/en-us/111900 or the equivalent current advisory page.

Heracles and the FHE Hardware Race — Computing on Data You Never Decrypt

Heracles and the FHE Hardware Race — Computing on Data You Never Decrypt

What Intel's new chip means for the future of privacy-preserving computation

---

I have been tracking fully homomorphic encryption for a while now — mostly as a theoretical boundary condition in my privacy-enhancing technologies research. The math has always been elegant. The performance has always been the problem. When a cryptographic operation takes tens of thousands of times longer than its plaintext equivalent, it lives in academic papers, not production systems.

That calculus is starting to shift. And the signal worth paying attention to right now is a chip called Heracles.

---

The Problem FHE Has Always Had

Let me frame the core issue for practitioners who haven't delved deeply into this.

Fully homomorphic encryption is, at its conceptual heart, a way to perform arbitrary computations on encrypted data without ever decrypting it. The server doing the computation never sees the plaintext. The result is returned encrypted, and only the party holding the key can read it. For anyone building systems that handle sensitive data — medical records, financial transactions, genomic information, private AI queries — this is the Holy Grail of privacy architecture. You get the computing power of the cloud without handing your data to the cloud in the clear.

The catch has always been performance. FHE is computationally brutal. The encrypted data grows by orders of magnitude compared to the original plaintext. The operations required — polynomial transforms, a noise-cancelling process called bootstrapping, and some genuinely odd-named operations like "twiddling" and "automorphism" — are deeply inefficient on general-purpose CPUs. A CPU can do it, but slowly, burning roughly 10,000 more clock cycles for integer operations than it would on unencrypted data. GPUs excel at parallel computation but sacrifice the precision FHE demands. Nobody has yet built hardware that's actually right-shaped for this workload.

Until now, possibly.

---

What Intel Just Demonstrated

Last month at the IEEE International Solid-State Circuits Conference in San Francisco, Intel demonstrated

Heracles — a purpose-built FHE accelerator that has been under development for 5 years as part of a DARPA program. The headline numbers are striking enough to take seriously.

Compared to a top-of-the-line Intel Xeon server CPU, Heracles achieved speedups ranging from 1,074 to 5,547 times across seven key FHE operations. On the specific benchmark Intel ran publicly — a private voter ballot verification query against an encrypted database — the Xeon took 15 milliseconds. Heracles did it in 14 microseconds. For a single query, that difference is imperceptible. At 100 million queries, you are looking at more than 17 days of CPU work versus 23 minutes on Heracles.

The demo itself is worth understanding because it illustrates exactly why FHE matters for real institutional use cases. A voter wants to confirm her ballot was recorded correctly. The government holds an encrypted database of voters and votes. Using FHE, the voter encrypts her own ID and ballot choice on her end and sends the encrypted query to the server. The server determines whether it matches the encrypted database using the encrypted query — without ever decrypting either. It returns an encrypted result. The voter decrypts it on her side. At no point does the government's computation infrastructure see either the voter's identity or her ballot in plaintext.

That is a meaningful security architecture. And until very recently, it was practically unusable at scale.

---

What Makes Heracles Different

Heracles is not a tweak to existing silicon. It is a ground-up rethinking of what an FHE workload actually needs.

At its physical core, the chip is built on Intel's most advanced 3-nanometer FinFET process — the same technology Intel uses for its best products — and measures roughly 200 square millimeters, about 20 times larger than competing FHE research chips. It is flanked in a liquid-cooled package by two 24-gigabyte high-bandwidth memory chips, a configuration you normally see only in AI training GPUs. That memory decision is telling: the data explosion problem in FHE is as much about bandwidth as it is about compute, and Intel has treated it accordingly, pairing 819 GB-per-second memory connections with 9.6 terabytes-per-second on-chip data movement.

The compute architecture centers on 64 SIMD cores — called tile-pairs — arranged in an 8x8 grid, connected by a 2D mesh network with 512-byte buses. These cores are purpose-built to run the polynomial arithmetic and transform operations required by FHE, performing them in parallel rather than serially. The chip runs three synchronized instruction streams simultaneously: one managing data into and off the processor, one managing internal data movement, and one running the arithmetic. This is the kind of design discipline that comes from five years of focused engineering on a single problem.

One architectural bet made early in the Heracles project deserves attention. The team chose to work in 32-bit arithmetic chunks rather than 64-bit, even though FHE requires much larger numbers. This seems counterintuitive — FHE demands precision on very large integers — but by breaking those large numbers into 32-bit pieces that can be computed independently, they gained significant parallelism. The 32-bit circuits are physically smaller, fit more of them on the die, and can run simultaneously. It was a risky design call that appears to have paid off.

---

The Competitive Landscape

Intel is not alone in this race, and the ecosystem developing around FHE hardware is worth watching closely.

Duality Technology, an FHE software firm whose CTO, Kurt Rohloff, described the Heracles results as "very good work," was part of a competing accelerator team in the same DARPA program. Duality's position is instructive: they are focused less on new hardware and more on software products for the kinds of encrypted queries Intel demonstrated. Rohloff's view is that at current scales, software is sufficient — specialized hardware becomes necessary as workloads shift toward deeper machine learning operations such as neural networks, LLMs, and semantic search.

Niobium Microsystems, a chip startup spun out of another DARPA competitor, is positioning itself as "the world's first commercially viable FHE accelerator." It recently announced a deal worth approximately $6.9 million with Seoul-based chip design firm Semifive to develop its FHE accelerator for fabrication on Samsung's 8-nanometer process. Intel has not yet announced commercial availability plans for Heracles, which gives Niobium an interesting window.

Other players — Fabric Cryptography, Cornami, and Optalysys — are building their own approaches. The most technically distinct is Optalysys, whose CEO Nick New argues that Heracles represents roughly the ceiling of what a fully digital approach can achieve. Optalysys is using photonic chips to perform FHE's compute-intensive transform steps using the physics of light rather than digital logic. Their photonic chip is on its seventh generation, and they are working toward a 3D-integrated commercial product — photonic chip for the transforms, custom silicon for the rest — potentially ready in two to three years. If that works, it would push performance well beyond what any digital accelerator can achieve.

---

What This Means for AI and Sensitive Data Workloads

Here is where this gets immediately relevant to the work I do at the intersection of AI governance and privacy architecture.

The scenarios that FHE hardware makes practical for the first time are exactly the ones that have been architecturally stuck. Federated learning, where contributors cannot trust the aggregation layer. Inference on private user data where neither the query nor the model weights should be visible to the infrastructure. Encrypted database search where even the server processing the query cannot see what was asked or what was found.

Duality's demonstration of an FHE-encrypted transformer model — a smaller-scale version of BERT — points toward the trajectory. Today it works on compact models. As hardware improves, the model size that FHE can accommodate in a reasonable time scales up with it. The end state, which feels meaningfully closer than it did twelve months ago, is AI inference that is provably private: the model provider cannot see your query, and you cannot extract the model weights. That is a different trust model than anything we have today with cloud AI APIs.

John Barrus at Niobium put it plainly: "There are a lot of smaller models that, even with FHE's data expansion, will run just fine on accelerated hardware." I believe him. And as someone who has spent the past year deep in agentic AI risk research, I find the prospect of AI agents operating on encrypted data without ever seeing plaintext personally significant. It changes what is possible in high-sensitivity deployment environments.

---

My Read on Where This Is Heading

Sanu Mathew, who leads security circuits research at Intel, described Heracles as "like the first microprocessor — the start of a whole journey." That framing is either marketing or genuine conviction, and in this case, I think it is the latter.

FHE has been a "maybe someday" technology for long enough that healthy skepticism is warranted. But the confluence of DARPA investment, Intel's 3nm engineering resources, multiple serious startups with real capital, and a photonics approach that could push past digital limits — this is not the same landscape as five years ago. The hardware is catching up to the math.

For practitioners building privacy architectures today, I would hold the following positions. Confidential computing with TEEs remains the most immediately deployable option for protecting data in use — its operational maturity and cloud provider support are in place, and the performance overhead is manageable. FHE hardware is the one to watch for workloads where you cannot trust the compute environment, even with hardware attestation, where the encryption must hold even against a fully compromised host. That scenario is rarer but more demanding, and it now has a credible hardware roadmap.

The combination of TEE-based confidential computing for near-term deployments and FHE hardware for the most trust-hostile environments represents, in my view, the serious privacy architecture stack for the next decade. Both are moving faster than most security teams realize.

Keep watching this space. 

Confidential Computing and the Shrinking Trust Perimeter

 Why hardware-enforced isolation is moving from research curiosity to operational baseline

---

As a CIO, I am consistently frustrated by the gap between cloud providers’ promises and their actual guarantees. Migrating workloads to the cloud, especially those involving sensitive records or financial data, requires extending trust to infrastructure I neither own nor can fully audit. Provider administrators, hypervisors, and co-tenants all contribute to the threat surface, whether or not it is explicitly acknowledged.

Confidential computing is the most robust architectural solution I have encountered for this challenge. It does not require increased trust in the platform through policy or contracts. Instead, it makes platform trust unnecessary for specific high-sensitivity workloads, which is a significant distinction.

---

Rethinking the Threat Model from the Hardware Up

Traditional cloud security relies on a layered trust model: hardware is trusted, the hypervisor is mostly trusted, the operating system is somewhat trusted, and controls are applied on top of that. Confidential computing eliminates these layers.

With Trusted Execution Environments (TEEs), your data is decrypted only within a hardware-enforced securWith Trusted Execution Environments (TEEs), data is decrypted exclusively within a hardware-enforced secure enclave. The hypervisor, even if accessible to cloud administrators, cannot access this

data. Neither a compromised operating system nor other tenants can reach it. The security boundary is enforced at the hardware level, not through software policy.n. Before releasing keys or sensitive datasets to an enclave, a client can ask the enclave to verify which code is running and on which hardware. The enclave returns a signed attestation report — covering its code measurements and platform configuration — verifiable against the chip manufacturer's trust anchor. If the proof doesn't check out, no data flows. Trust becomes an enforceable predicate rather than a soft assumption.

This is especially relevant given NIST and CISA’s focus on zero-trust maturity. Remote attestation shifts the model from "trust but verify" to "verify, then trust—only for this workload, on this hardware, running this exact binary." This is a defensible position for a board audit committee.

---

Where I See the Real Institutional Use Cases

Sensitive data analytics without leaving your compliance posture behind

At Denver Seminary and in most higher education and nonprofit organizations I work with, the most critical data also faces the greatest regulatory constraints: student records under FERPA, donor financials, HR data, and research involving human subjects. Traditionally, this data remains on-premises, often resulting in reliance on costly, outdated infrastructure that limits analytical capabilities.

Confidential computing provides a balanced solution. Data is encrypted at the source, transmitted to the cloud, and decrypted only within a TEE. The cloud operator and hypervisor see only ciphertext. An authorized analytical process inside the enclave accesses plaintext, performs computations, and returns only permitted results. This architectural approach makes migrating sensitive workloads to the cloud a manageable risk rather than a compliance risk.

Federated AI without blind trust in the platform

Given my postdoctoral research at Harvard on agentic AI risks, I have closely followed federated learning. The concept—multiple parties contributing private data to a shared model without exposing their datasets—is compelling. However, platform trust remains a challenge. Who operates the aggregation layer, and what prevents them from inspecting contributions?

TEEs address this issue directly. Multiple institutions, such as hospitals, universities, and government agencies, can contribute to a shared training run within an enclave. Neither the platform operator nor other contributors can access individual data. This results in a richer model and improved data governance. Model weights can also be protected during inference, which is critical for institutions with proprietary model investments.

Confidential databases — a practical step most teams can take now

This is the use case I find most immediately actionable for teams not prepared to redesign their entire data architecture. Database engines operating within TEEs can process queries on encrypted data—performing filters, joins, and aggregations on decrypted values inside the enclave—without exposing those values to the operating system, DBA console, or cloud management plane. Sensitive columns remain encrypted except within the secure computation boundary.lly homomorphic encryption or private information retrieval in the most demanding scenarios. But for the vast majority of institutional database workloads — payroll, benefits, student records, donor data — it meaningfully closes the insider threat gap without requiring a wholesale re-architecture.

---

Honest About the Limitations

I want to be careful not to oversell this. TEEs are a significant. It is important not to overstate the benefits. TEEs represent a significant advancement, but they are not a comprehensive solution and have real limitations. The transitions carry cost, encrypted memory adds latency, and attestation rounds add startup time. For latency-sensitive workloads, this requires careful profiling. In my experience, most batch analytics and background AI inference workloads absorb it reasonably well. Interactive query workloads require more thought.

Hardware dependence is another constraint. TEEs require specific CPU features such as Intel TDX, AMD SEV-SNP, or ARM TrustZone. Not all cloud regions support these features, and edge or IoT environments present additional challenges. During my Harvard coursework, I observed that lightweight cryptographic primitives required by constrained devices do not align well with the current TEE model.

The residual attack surface is another important consideration. Side-channel attacks, such as Spectre-class timing and cache attacks, remain a concern for TEE implementations. Hardware supply chain integrity is also unresolved. While TEEs significantly reduce privileged insider risk, they do not eliminate all attack vectors. Treating TEEs as impenetrable is as risky as disregarding them entirely.

---

Where This Fits in: Confidential computing is part of a broader set of privacy-enhancing technologies, including secure multiparty computation (MPC), homomorphic encryption, differential privacy, zero-knowledge proofs, and synthetic data. Each addresses overlapping challenges with distinct trade-offs. The UN’s guidance on privacy-preserving statistical methods emphasizes that no single technique is universally superior. A single technique dominates.

TEEs offer operational practicality that most alternatives lack. Homomorphic encryption is mathematically robust but computationally intensive. MPC requires complex protocol design and multiple non-colluding parties. In contrast, TEEs require only modest changes to existing applications, effectively enclosing workloads within a hardware boundary rather than redesigning cryptographic foundations. This is particularly valuable for institutions with established codebases and limited engineering resources.

---

A Practitioner's Starting Point

If advising a peer CIO interested in piloting this technology, I would recommend the following sequence: a microservice is ideal — small attack surface, clear data sensitivity, easy to instrument. Move just that into a confidential VM or confidential container offering from your cloud provider. AWS, Azure, and Google Cloud all expose TEE capabilities through familiar VM and Kubernetes abstractions at this point; the barrier to entry is lower than most teams assume.

Integrate attestation from the outset. The attestation process, in which the application’s startup sequence requests proof of the enclave’s identity before releasing keys, provides the core security guarantee. Without attestation, a TEE does not deliver its intended protection.

Next, evaluate performance, operational overhead, and incident response complexity. Build institutional knowledge before expanding the deployment scope.

For those involved in AI governance, sensitive data analytics, or cross-institutional data sharing—which encompasses many critical technology challenges in higher education, healthcare, and government—confidential computing is becoming a baseline expectation rather than a niche research topic. The key architectural question is not whether to adopt it, but how it fits within your threat model and which workload to prioritize.

Only the code you chose, running in an attested hardware enclave, should ever see your data in the clear. That is a principle worth building toward.

Zero Trust Architecture - Implementation Challenges Analysis on a Paper

In one of the assigned readings, I read the paper  "A systematic literature review on the implementation and challenges of Zero Trust Architecture across domains" by Mustaq Ali et al., which reviews about 74 studies from 2016 to 2025. It explores how Zero Trust Architecture (ZTA) has been used across various technical and organizational scenarios and highlights the challenges encountered in these implementations.

In a previous course I took at Harvard (CSCIE-155, Networks & Security), I read Project Zero Trust by George Finney, which presents Zero Trust Architecture as a story. I recommend this one because it narrates the problem beautifully, in novel style: a hacker holds a fitness company hostage by stealing PII and threatening to make it public, and how the company's responders are beginning to implement Zero Trust Architecture to combat the attack and prevent future infiltrations and hacks. This paper spotlights the same core principles in its introduction. According to Finney (2022), ZTA is a strategy, not just a tool, yet the industry often treats it as a tool or framework. This difference is important and a key theme in Mushtaq et al.'s (2025) literature review.

Finney (2022) outlines six fundamental principles that define ZTA as a strategy rather than a product:
The first principle is to identify and define the protected surfaces. Instead of securing the whole network at once, organizations should focus on what needs protection most—the "Crown Jewels." Finney (2022) calls these DAAS: Data, Assets, Applications, and Services, which are the most important resources the organization must protect.

The second principle is to map transaction flows. This entails understanding how data flows within the organization, documenting how users and systems interact with protected surfaces, and defining normal traffic patterns (Finney, 2022).

Third, the focus moves to designing the network. This requires a careful, robust approach to micro-segmentation, creating a custom environment for each protected surface with micro-perimeters. Finney (2022) explains this as the "Kipling Method" Gateway, which is a specific entry point designed for each surface.

Fourth, organizations need to set a Zero Trust policy. The "Kipling Method," as Finney (2022) describes, involves formulating detailed rules about Who, What, When, Where, Why, and How traffic is allowed. Each access decision adheres to clear, context-based criteria.

The fifth and sixth principles go together: monitor and keep visibility using analytics, and keep improving over time. A security team that checks and logs all traffic in real time can spot problems and find ways to improve. This monitoring leads to regular reviews of protected surfaces and policies, helping organizations adjust to new threats and changing business needs (Finney, 2022).
With Finney's (2022) strategy in mind, the results of this literature review stand out. Mushtaq et al. (2025) show that, although the industry uses the language of Zero Trust, it has only partially put its ideas into practice across 74 studies.

The Gap Between Principle and Practice

Mushtaq et al. (2025) found that most ZTA implementations in all areas focus mainly on the basics: authentication, authorization, and access control. These are important, but they are only part of what a real Zero Trust setup needs.

What's consistently missing? Continuous auditing and monitoring, automated policy orchestration, and environmental or context-aware perception (Mushtaq et al., 2025). Mapped against Finney's (2022) principles, this means the industry has made progress on establishing policies and verifying identity (principles three and four), but has largely neglected the transaction flow mapping, immediate monitoring, and continuous improvement cycles (principles two, five, and six) that make Zero Trust a living strategy rather than a static configuration.
In other words, most organizations have locked the front door but have not installed cameras, alarms, or systems to detect when something is wrong inside. They have treated Zero Trust as just a tool, which is exactly the mistake Finney (2022) warns about.

Where It's Working — and Where It Isn't

Cloud and enterprise environments have made the most progress toward mature ZTA implementations (Mushtaq et al., 2025). This makes sense — these domains have mature tooling, well-defined architectural patterns, and the resources to commit to comprehensive security redesigns. Remote work acceleration during and after the pandemic pushed many enterprises to adopt Zero Trust principles out of necessity, and cloud providers have built native support into their platforms.
The story changes dramatically when you look at other domains. Two stand out as particularly challenging.

IoT: Too Constrained for Full Zero Trust

The Internet of Things represents one of the most difficult frontiers for Zero Trust adoption. Mushtaq et al. (2025) identified 11 IoT-focused studies, making it the second-most-studied domain — a reflection of both its importance and its complexity. The fundamental problem is resource constraints. IoT devices — sensors, embedded controllers, industrial monitors — often run on minimal processing power, limited memory, and constrained battery life. The cryptographic operations that Zero Trust demands (continuous authentication, encrypted communications, and token validation) can overburden these devices or drain them faster than they can be maintained (Mushtaq et al., 2025).

The authors identify a major gap: the lack of lightweight cryptographic solutions customized to these environments (Mushtaq et al., 2025). Standard enterprise-grade security protocols simply don't translate to a temperature sensor running on a microcontroller. Until the security community develops cryptographic approaches that are simultaneously robust and resource-efficient, IoT Zero Trust implementations will remain experimental and incomplete.

There's also the scale problem. An enterprise might manage thousands of user accounts. An IoT deployment may include tens of thousands of devices, each requiring its own identity and generating its own trust signals. The orchestration challenge alone is staggering, and most current solutions don't handle it well. Through Finney's (2022) lens, identifying and defining protected surfaces in an IoT environment — where DAAS elements are distributed across thousands of constrained devices — becomes exponentially more complex than in a traditional enterprise setting.

Healthcare: Where Compliance and Architecture Collide

Healthcare was the third-most-studied domain, with 7 studies, and it presents a distinct yet equally instructive set of challenges (Mushtaq et al., 2025). Here, the issue isn't primarily about device constraints — it's about the collision between Zero Trust principles and regulatory reality.
Healthcare organizations operate under strict frameworks such as HIPAA in the United States and the GDPR in Europe. These regulations have specific requirements around data access, audit trails, patient consent, and breach notification. Mushtaq et al. (2025) found that most ZTA implementations in healthcare struggle to fully conform to these frameworks, particularly in data administration, continuous auditing, and the explainability of automated access decisions.
Consider the tension: Zero Trust calls for dynamic, context-aware access decisions — a system might grant or revoke access to patient records based on real-time signals such as device health, location, or behavioral patterns. But HIPAA necessitates clear, auditable justification for every access decision. When an AI-driven trust engine denies a clinician access to a patient's records during a critical moment, the organization needs to explain exactly why — and the current generation of context-aware trust engines often can't provide that level of transparency.

This is where Finney's (2022) Kipling Method becomes both essential and difficult to execute. Writing granular rules based on Who, What, When, Where, Why, and How is precisely what healthcare regulators demand — but doing so dynamically, at scale, across a hospital's sprawling ecosystem of electronic health records, medical devices, telemedicine platforms, pharmacy systems, and insurance integrations is still a largely unsolved challenge.

What Needs to Happen Next

Mushtaq et al. (2025) don't just catalog problems—they point to a clear set of priorities for the field, many of which correspond directly with the strategic vision Finney (2022) articulated.
First, lightweight cryptography needs to move from research curiosity to production reality. Without it, Zero Trust will remain impractical for the fastest-growing categories of connected devices (Mushtaq et al., 2025).

Second, context-aware trust engines need to become more sophisticated and more transparent. Dynamic access decisions are powerful, but only if they can be audited, explained, and consistent with the regulatory contexts where they operate (Mushtaq et al., 2025).

Third, orchestration cannot be an afterthought. The hardest part of Zero Trust is not checking a single request, but rather maintaining a clear, enforceable policy across multiple systems simultaneously (Mushtaq et al., 2025). Finally, regulatory integration should be planned from the beginning, not added after the system is built. The difference between what Zero Trust systems do and what regulations require them to record is a major barrier to adoption (Mushtaq et al., 2025).

The Bottom Line

Zero Trust is the right approach. The idea of "never trust, consistently verify" makes sense in a world devoid of clear boundaries and rife with threats. However, this review shows that the industry is still in its early stages. Most implementations focus solely on access control and overlook the monitoring, orchestration, and compliance features that enable Zero Trust to function effectively (Mushtaq et al., 2025).

As Finney (2022) reminds us, Zero Trust is a strategy. It is a cycle of identifying what matters most, understanding how it is accessed, building protections, writing explicit policies, monitoring everything, and continually improving. The 74 studies reviewed by Mushtaq et al. (2025) show that the industry has started this journey, but still has a long way to go. The areas where this is most important—IoT, healthcare, and industrial systems—are also where the risks are highest. Getting Zero Trust right in these fields is not only a technical task. It is essential.

References

Finney, G. (2022). Project Zero Trust: A story about a strategy for aligning security and the business. Wiley.

Mushtaq, S., Mohsin, M., & Mushtaq, M. M. (2025). A systematic literature review on the implementation and challenges of Zero Trust Architecture across domains. Sensors, 25(19), 6118.

On Neumann's Paper "Towards Total-System Trust worthiness"- We're Building Houses of Cards

As one of my New Year's goals, I have committed to writing a few blog posts a month, and this is a good opportunity to use class work to express my rants and ramblings while getting some learning done in the process.  

Peter G. Neumann is a legend in computer security for good reason. His article "Toward Total-System Trustworthiness" names something most of us in technology leadership sense but rarely articulate: we're playing a losing game. Every patch, every wrapper, every clever workaround adds another card to a structure that was never designed to bear the weight we're placing on it.

The Southwest Airlines meltdown brought this into sharp relief. A classmate in the discussion posts that I answered to earleir today pointed out that their catastrophic failure during the winter storm wasn't a technology problem—it was an archaeology problem. Southwest had essentially wrapped an old 1990s-era scheduling system called SkySolver in newer interfaces, hoping the wrapper would compensate for foundations that were never updated for modern scale. When the storm hit, the sheer volume of data overwhelmed the underlying logic, and no amount of clever interfacing could save it.

Neumann calls this the "patch-on-patch" approach. I call it "technical debt" from days in software engineering and leading developers or product development teams, which come with haunting reminders of bug fixing and facing the music from unhappy customers, all coming due with compound interest.

Why Total-System Trustworthiness Remains Elusive

After twenty-plus years leading technology operations across global organizations, I've come to believe there are four fundamental reasons why achieving true system trustworthiness remains aspirational at best—especially when you're simultaneously responsible for keeping the lights on.

The "Less Untrustworthy" Objective: The "Less Untrustworthy" Objective. People tend to use simple binary categories when evaluating systems because they believe these systems exist in only two states: secure or insecure, and trustworthy or broken. Neumann presents this concept as a gradient that transforms the entire system. The main priority should be to minimize untrustworthy actions because we understand that humans will always fall short of achieving complete trust with one another. Medical practice requires drug interaction screening instead of achieving absolute treatment success. In systems, it means assuming your components will fail and engineering the resilience to absorb it.

The Legacy Trap: The Legacy Trap. Neumann supports a complete system reset approach, which becomes necessary when organizations attempt to add security features to their existing, outdated systems. The process of building a dormitory becomes similar to this situation because the poured foundation creates physical boundaries that determine the building's shape. The fundamental basis of computer systems is rooted in the x86 architecture and the C programming language, which were developed when cyber warfare as we know it today did not exist. A sinking foundation will never achieve perfection because any attempt to fix it through retroactive correction will be unsuccessful. We can only shore it up and resolve to build the next one differently.

Anticipating the "Space Aliens: I am reminded of a computer game I used to play :) Anticipating the "Space Aliens."Security professionals defend against space aliens using a humorous method that illustrates a basic threat modeling principle that seems ridiculous at first. Neumann explains that we cannot predict all environmental elements, including floods, earthquakes, and zero-day exploits, but we should design systems that continue to function properly during decline. A dependable system produces clear, limited failures rather than complete system breakdowns.

Designing with Humility: The most crucial element runs counter to the industry's conventional values, as it requires organizations to delay their responses, even though speed and self-assurance are typically prized. Recognizing the unresolvability of complex systems makes us more likely to implement observation systems that detect failures and compartmentalization, thereby preventing a single-floor slab crack from collapsing the entire roof structure, and to use formal methods to verify our ability to control specific system components.

The Leadership Paradox

The main thing that prevents me from sleeping is that technology leaders receive existing systems rather than designing their own. The situation forces us to take on dual responsibilities: maintaining existing systems and establishing their trustworthiness. The problem stems from organizational and philosophical factors rather than being a technical issue. Neumann shows that we need to stop using short-term security fixes and instead actively discuss fundamental system vulnerabilities. Our organization will protect against future system failures through our commitment to humility and our practice of sharing all operational procedures with others.

Our systems will inevitably experience failure, according to the question. We need to understand whether we can develop systems that will collapse yet still enable us to survive.

 

When Algorithms Shape Reality: How AI and Social Media Are Rewiring How We Think

Last November, Adam Aleksic delivered a five-minute TED talk that landed harder than presentations three times its length. His premise is deceptively simple: the AI tools and platforms we use daily aren't showing us reality—they're showing us a filtered, amplified, distorted version of it. And we're absorbing that distortion without realizing it.

I've been sitting with this one for a while. As someone who lives at the intersection of technology strategy and organizational transformation, I recognize the pattern Aleksic describes. I've seen it play out in enterprise systems, in user behavior, in the subtle ways digital tools reshape the humans who use them.

The Language We're Learning Isn't Ours

Here's the detail that stopped me cold.

ChatGPT uses the word "delve" at rates far exceeding normal English usage. The likely explanation? OpenAI outsourced portions of its training process to workers in Nigeria, where "delve" appears more frequently in everyday speech. A minor linguistic quirk from a specific population was reinforced during training and is now reflected among hundreds of millions of users worldwide.

But it doesn't stop there. Multiple studies have found that since ChatGPT's release, people everywhere—not just users—have started saying "delve" more often in spontaneous conversation. We're unconsciously absorbing the AI's patterns and mirroring them back.

As Aleksic puts it: "We're subconsciously confusing the AI version of language with actual language. But that means that the real thing is, ironically, getting closer to the machine version of the thing."

Read that again. The real is conforming to the artificial.

The Feedback Loop No One Asked For

This isn't just about vocabulary. Aleksic points to Spotify's "hyperpop" genre as a case study in algorithmic reality creation.

The term didn't exist in our cultural vocabulary until Spotify's algorithm identified a cluster of similar listeners. Once the platform created a playlist and gave the phenomenon a label, it became more real. Musicians started producing hyperpop. Listeners began identifying with or against it. The algorithm continued to push, and the cluster expanded. What started as an algorithmic observation became a cultural movement.

The same pattern drives viral trends—matcha, Labubu toys (the world is going crazy), and Dubai chocolate (I see them everywhere from Costco to World Market). An algorithm identifies latent interest, amplifies it among similar users, and, suddenly, businesses and influencers create content around what may have been an artificially inflated trend. We lose the ability to distinguish between organic cultural shifts and manufactured momentum.

The Uncomfortable Question

Aleksic doesn't shy away from the deeper implications.

"Evidence suggests that ChatGPT is more conservative when speaking the Farsi language, likely because the limited training texts in Iran reflect the more conservative political climate in the region."

If AI systems inherit the biases of their training data—and they do—what happens when millions interact with those systems daily? What range of thoughts do we stop considering because the algorithm never surfaced them? What possibilities get filtered out before we ever encounter them?

Elon Musk regularly modifies Grok's responses when he disagrees with them, then uses X to amplify his own content. Aleksic asks the obvious question: Are millions of Grok and X users being subtly conditioned to align with Musk's ideology?

These platforms aren't neutral. Everything in your feed or your chatbot response has been filtered through layers of optimization—what's good for the platform, what makes money, and what conforms to the platform's necessarily incomplete model of who you are.

Thinking About Thinking

Twenty-two years in global technology leadership has taught me something about systems: they shape behavior far more than we acknowledge. The tools we build eventually build us. The interfaces we design become the cognitive architecture through which users experience their work, their relationships, their world.

What Aleksic describes is that phenomenon at civilizational scale.

"TikTok has a limited idea of who you are as a user," he notes, "and there's no way that matches up with your complex desires as a human being."

And yet we scroll. We engage. We absorb. We mirror back.

The Only Defense

Aleksic's antidote is persistent self-interrogation:

Why am I seeing this? Why am I saying this? Why am I thinking this? Why is the platform rewarding this?

Simple questions. Difficult discipline.

"If you're talking more like ChatGPT," Aleksic concludes, "you're probably thinking more like ChatGPT as well, or TikTok or Spotify. If you don't ask yourself these questions, their version of reality is going to become your version of reality."

There's something almost spiritual in that warning. The ancient disciplines of self-examination—examine yourselves to see whether you are in the faith—take on new urgency when the voices shaping our inner dialogue aren't human at all.

The question isn't whether these tools are useful. They are. The question is whether we're using them—or being used by them.

Stay awake. Stay questioning. Stay real.