The @European Commission has released an update to patch out the issues I raised last week, v2026.04-2 (https://ageverification.dev/releases/#release-notes_1…) Honestly, I don't know if I should laugh or cry. Let's review each one: 1. On-device data: database and settings encrypted at rest, with keys protected by the device’s hardware-backed key store. Sounds great, until you look closer. They introduced http://androidx.security:security-crypto, deprecated in 2025. Also http://androidx.security.crypto.EncryptedSharedPreferences, deprecated in 2025. Finally, http://androidx.security.crypto.MasterKeys, which were deprecated in 2020. 3 deprecated dependencies introduced following criticism over weak security. These weren't left over and missed during an update... they've added them now to "harden security". Remember, this isn't an isolated app. It's intended to lay the foundation for many production applications; all using deprecated security libraries from the outset. Worse, they already correctly use KeystoreController in their codebase. The correct answer already existed and they still got it wrong. 2. Runtime: the app checks device integrity on startup and refuses to run on rooted or jailbroken devices. Production deployments should complement it with stronger device-attestation mechanisms appropriate to their infrastructure and compliance requirements. They check for su, check package manager for root apps, run "which su" and checks if it's a custom ROM. Paths: /system/bin/su /system/xbin/su /sbin/su /system/su /data/local/su /data/local/bin/su /data/local/xbin/su /system/app/Superuser.apk /system/app/SuperSU.apk Great... in 2015. These are all trivially bypassed in 2026. 3. Passport onboarding: more stable scanning; the passport photo is stored privately and deleted as soon as it’s no longer needed. They're still not encrypted, so I'm not sure what "privately" means - but they are deleted correctly now. 4. PIN: stricter rules block easy-to-guess PINs; PINs are salted and hashed, never stored in plain form. They salt correctly (a true CSPRNG), then use PBKDF2-SHA256 - which is outdated and only recommended where FIPS compliance is required, which doesn't apply here. To make matters worse, they use just 210,000 iterations. For those of a NISTy disposition, you're likely already shaking your head. 210,000 seems oddly specific. It is. It's the @OWASP® Foundation minimum for PBKDF2-SHA512, not SHA256. Right number, wrong algorithm. In reality, OWASP recommended 600,000 iterations as a minimum in 2023. Worse still, 600,000 is the baseline minimum for passwords, not PINs with 1 million permutations. You could use 1B iterations, you're not measurably increasing security when there are so few attempts required to break it. At the very least, use a modern hash with reasonable brute-force resistance against a 2026 threat model. All this... cited as a "first hardening step". Again, utter security theatre. None of this negates my fundamental point. This isn't fixable through code - it's fundamentally ill-conceived and poorly implemented.