Notifications
Clear all
Topic starter
18/08/2026 2:25 pm
TL;DR: No-code, vendor-controlled encryption can create lock-in when the vendor owns both the encryption routine and the keys, leaving stored customer data unreadable after a tool switch, according to Guardsquare. The underlying lesson is that security tooling must not take custody of critical assets if migration, auditability, and operational control need to remain with the organisation.
NHIMG editorial — based on content published by Guardsquare: Let Me Out: Encryption-Driven Vendor Lock-in
Questions worth separating out
Q: What breaks when encryption keys are controlled by a vendor instead of the organisation?
A: The organisation may lose the ability to decrypt, migrate, or re-encrypt its own data when the tool changes.
Q: Why does clean core matter for identity and access governance?
A: Clean core matters because it changes where controls can live.
Q: How can security teams avoid being trapped by outsourced protection features?
A: They should require demonstrable control over keys, decryption logic, and data export before adoption.
Practitioner guidance
- Define key custody before adopting managed encryption Require that the organisation can generate, rotate, revoke, and recover keys without vendor dependency.
- Test migration with encrypted production-like data Prove that protected files can be re-read after a tool swap or policy change.
- Separate protection logic from business data ownership Keep sensitive business data, encryption decisions, and recovery procedures under organisational control, while using vendor tooling only for secondary hardening functions.
What's in the full article
Guardsquare's full article covers the implementation details this post intentionally leaves at the governance level:
- The no-code encryption pattern that wrapped file read and write operations in the mobile app
- How vendor-controlled keys prevented readable access after the tool swap
- The in-house encryption example showing how organisations can keep data and logic under their own control
- The step-by-step hardening approach that keeps source assets portable while still using vendor protection tools
👉 Read Guardsquare's analysis of encryption-driven vendor lock-in in mobile protection →
Encryption-driven vendor lock-in: what mobile security teams missed?
Explore further
18/08/2026 3:16 pm
Control over cryptographic authority is the real security boundary. The article shows that encryption can be technically sound while still being strategically unsafe if the organisation does not control the keys and decryption routine. That distinction matters in identity governance too, where delegated services, tokens, and trust relationships often outlive the teams that approved them. Practitioners should evaluate who can still prove access when the tooling changes.
A question worth separating out:
Q: Should organisations treat encryption controls like privileged services?
A: Yes. Any control that can determine whether data is readable should be governed like privileged access, with ownership, review, and exit requirements. That means clear accountability for key custody, regular testing of recovery procedures, and a written offboarding plan before the control is allowed to protect production data.
👉 Read our full editorial: Encryption-driven vendor lock-in shows why data control matters
