Microsoft terminates VeraCrypt account, halting Windows updates

Original Article ↗ Hacker News Discussion ↗

Microsoft account termination and blast radius

  • Thread views the VeraCrypt signing-account shutdown as part of a broader pattern: Microsoft can unilaterally break critical third‑party software that depends on its signing/driver infrastructure.
  • Other projects reportedly hit: WireGuard-related account, Windscribe, 5eplay.com, and “a bunch” of driver developers and companies via Partner Center lockouts.
  • Several note the lack of human support or appeal path and describe Trusted Signing verification as brittle and inconsistent, especially for small orgs and non‑US entities.
  • Some suspect this is Microsoft nudging developers onto Trusted Signing; others hint at possible regulatory/geopolitical pressure, but motives are acknowledged as unclear.

Executable signing & Secure Boot: security vs. control

  • One camp argues executable signing and Secure Boot mainly serve vendor control: deciding what users may run, training people to accept locked devices, and enabling ecosystem lock‑in (parallels drawn to iOS and Android).
  • Opposing camp stresses real security benefits: protection against bootkits, kernel‑mode malware, firmware tampering, and “evil maid” attacks; essential for practical full‑disk encryption (FDE) with TPM.
  • Embedded / money‑handling and safety‑critical systems are widely seen as legitimate beneficiaries of Secure Boot.
  • Critics respond that:
    • Most users’ actual threats (ransomware, stalkerware) aren’t mitigated much by SB.
    • Boot‑level malware was historically rare; SB has had many bypasses and key leaks.
    • Disabling SB is often impractical on phones and some PCs, and embedded devices frequently burn vendor keys permanently.
  • Supporters emphasize users can (in principle) disable SB or enroll their own keys; opponents counter that this is too complex for normal users and increasingly blocked by software and mobile apps.

Full‑disk encryption: VeraCrypt vs. BitLocker/TPM

  • Some prefer VeraCrypt‑style FDE with a passphrase/keyfile and no reliance on motherboard secrets or cloud escrow.
  • Others argue TPM‑backed BitLocker with optional PIN is more secure in practice and far easier for non‑experts; OneDrive key upload can be disabled.
  • Disagreement over whether TPM‑only unlock on the original motherboard is acceptable security if a laptop is stolen.

Microsoft, lock‑in, and OS choices

  • Many see this incident as another example of Microsoft’s long‑running strategy: vendor lock‑in, surveillance, “enshittification” of products (Windows 11, Copilot, Teams, GitHub), and obstructing non‑Microsoft ecosystems.
  • Some broaden the criticism to the whole tech industry; others highlight Apple’s iOS browser and app‑store restrictions as a parallel form of holding back progress.
  • Multiple commenters describe personal or organizational migrations from Windows/SSIS/Office 365 to Linux, macOS, PostgreSQL, and FOSS tools, often citing privacy and control.
  • Linux is portrayed as increasingly polished (Valve/Steam Deck, gaming improvements), though proprietary apps like SolidWorks/Fusion 360 remain blockers for some.

Code signing ecosystem and potential reforms

  • Many resent that FOSS authors must pay commercial CAs (sometimes hundreds of dollars per year) just to distribute free Windows software; some call code signing a “scam.”
  • Others argue a moderate price floor is useful to keep out low‑effort malware, as long as it’s “trivial for serious developers.”
  • Ideas floated:
    • A central, independent signing authority for open source or foundation‑backed signing (with reproducible/audited builds).
    • Existing FOSS‑friendly CAs (e.g., Certum, Comodo) and projects like ossign.org as partial solutions.
  • Counter‑arguments note that centralization creates a powerful, corruptible chokepoint and further encourages locked‑down computing; current distro‑level signing (Debian, Arch, etc.) is seen as a healthier, decentralized model.