Context: Protected data needs to be used. There are many types of entities which might attempt to use the data.
Problem: If no standard way of accessing data exists, then each entity might attempt to build its own system for handing the sensitive data. The data access layer might be implemented over and over again by each entity, without reuse of known best practices and with a lot of code duplication.
- Code duplication: if each entity attempts to write its own routines for data access, invariably this will bring duplication.
- No knowledge reuse: if a bug is found and fixed in one of the implementations, there is no guarantee that all the other implementations will be updated. For example
- Double-Encryption: lack of care or knowledge could lead a NAV developer to attempt to double-encrypt strings, which would render them unusable.
- Multi-company configuration : in NAV, it is possible to store multiple companies on the same tenant  database. A developer who has not investigated such a configuration and its consequences on encryption, can attempt to encrypt data in (for example) a Setup Table  of only one company, which would make this table unusable from any unencrypted company (since the server will observe that encryption is enabled, and try to retrieve it as it were enabled for all companies and fails).
- “Shotgun surgery” : one change in the data access technique (like a new requirement to validate the user’s identity before viewing any protected data), calls for updates in every single implementation of data access, if multiple implementations exist. Hence, one change of requirement triggers multiple efforts to update the product.
Solution: In Dynamics NAV the same library which offers Encryption, is also intended to be used as a Single Point of Access. Write code to create, read and remove sensitive data only through codeunit 1266 Encryption Management, and never directly.
Read more on NAV Design Patterns wiki site…
By Bogdana Botez at Microsoft Development Center Copenhagen