In today’s digital landscape, data security is no longer optional. Organizations using Dynamics 365 Finance & Operations (D365FO) handle sensitive information such as customer records, financial transactions, banking details, integration credentials, and regulatory data. Protecting this information from unauthorized access is a critical requirement.

To address this need, D365FO provides built-in encryption and decryption mechanisms that safeguard sensitive data both at rest and in transit. These mechanisms ensure that confidential information remains secure while still being accessible to authorized business processes and users.

At its core, encryption converts readable information (plaintext) into an unreadable format (ciphertext) using a cryptographic key. Decryption performs the reverse operation, transforming encrypted data back into its original form when the correct key is available.

Why Encryption Matters in D365FO

Encryption plays a critical role in safeguarding sensitive business information. Common use cases include:

• Storage of API secrets and access tokens
• Banking and payment-related information
• Integration credentials
• Sensitive configuration parameters
• Confidential business data
• Secure communication between services

Without encryption, anyone with database access could potentially read sensitive information directly from SQL tables. Encryption ensures that even if the data is exposed, it remains unreadable without the appropriate decryption key.

Encryption in D365FO: A Two-Layer Approach

Encryption at rest

Microsoft automatically protects data stored within Finance and Operations environments using:

• SQL Server Transparent Data Encryption (TDE)
• Azure Storage Encryption
• Service-managed encryption keys
• Automatic key rotation and management

Even if someone gains direct access to the database files or storage layer, the information remains encrypted and inaccessible without the proper encryption keys.

Field-Level Encryption

While encryption at rest protects the entire database, D365FO also provides field-level encryption for highly sensitive values.

Two commonly used methods are:

Global::editEncryptedField()

Global::editEncryptedStringField()

These methods use environment-specific encryption certificates to encrypt individual field values before they are persisted to the database.

This creates an additional security layer beyond SQL Server and Azure Storage encryption.

Real-World Example: SMTP Password Encryption

A standard Microsoft implementation can be found in the Email Parameters setup.

When an SMTP password is entered:

• The value is never stored as plain text.
• The field uses the EDT EncryptedField.
• The data is encrypted before being written to the database.
• Authorized processes can decrypt and retrieve the value when required.

These encrypted fields aren’t stored as plain text in the database, instead they’re encrypted (as its name suggests) using a key and that value is saved.

How D365FO Handles Encrypted Fields

How does it work in the background?

The table ‘SysEmailSMTPPassword’ has the field ‘Password’ with the EDT as ‘EncrytpedField’

When users enter a password, the field behaves like a typical password control, displaying masked characters instead of the actual value.

The form does not directly bind to the database field. Instead, it relies on table methods that handle encryption and decryption:

/// <summary>
/// Display method for <c>SysEmailSMTPPassword</c>'s <c>Password</c> field
/// that catches exceptions.
/// </summary>
/// <param name = "_set">True if the password is being updated. False if it is being read.</param>
/// <param name = "_value">New password value.</param>
/// <returns>Current password value.</returns>
public edit SMTPPassword passwordEditWithExceptionHandling(boolean _set, SMTPPassword _value)
{
    System.Exception ex;
    SMTPPassword password = '';
    try
    {
        password = this.passwordEdit(_set, _value);
    }
    catch (ex)
    {
        boolean exceptionNested = false;
        while (ex != null)
        {
            EmailEventSource::EventWriteSysEmailSMTPPasswordFailure(
                tableStr(SysEmailSMTPPassword) + '.' + tableMethodStr(SysEmailSMTPPassword, passwordEditWithExceptionHandling),
                ex.Message,
                ex.GetType().FullName,
                ex.StackTrace,
                exceptionNested,
                _set ? 'set' : 'get');
            exceptionNested = true;
            ex = ex.InnerException;
        }
        if (_set)
        {
            warning("@ApplicationFoundation:SysEmailSMTPPasswordWriteFailureMessage");
        }
        else
        {
            warning("@ApplicationFoundation:SysEmailSMTPPasswordReadFailureMessage");
        }
    }
    return password;
}

 public edit SMTPPassword passwordEdit(boolean _set, SMTPPassword value)
 {
     return Global::editEncryptedField(this, value, fieldNum(SysEmailSMTPPassword, Password), _set);
 }

The system automatically handles the encryption of sensitive fields before a record is inserted/updated to the database

public void insert()
{
    boolean success = false;
    try
    {
        Global::handleEncryptedTablePreInsert(this);
        super();
        Global::handleEncryptedTablePostInsert(this);
        success = true;
    }
    finally
    {
        this.auditLogging(success);
    }
}
public void update()
{
    boolean success = false;
    try
    {
        Global::handleEncryptedTablePreUpdate(this);
        super();
        Global::handleEncryptedTablePostUpdate(this);
        success = true;
    }
    finally
    {
        this.auditLogging(success);
    }
}

The above logic can be handled in table extensions/ custom tables.

I implemented the above approach in a custom table. Given below the steps:

1. Create a new field AE_Password’ in my custom table and map the EDT ‘EncryptedField’
2. My custom table has the below method which will be have the logic of encryption

public edit AEPassword passwordEdit(boolean _set, AEPassword value)
{
    return Global::editEncryptedField(this, value, fieldNum(AECustomTable, AE_Password), _set);
}

3. Also incorporate the handling of encryption in insert/update method

4. Now a string field is created in the form and referred my custom table and the above method.

5. Compile and sync.

Best Practices

Use EncryptedField EDT for passwords, tokens, and secrets.

Avoid storing credentials in plain text fields.

Utilize standard framework methods rather than custom encryption implementations.

Restrict access to encrypted data through security roles.

Combine field-level encryption with Microsoft’s built-in encryption at rest.

Avoid exposing decrypted values in logs, infologs, or telemetry.

What’s Next?

In my next blog post, we’ll dive deeper into Symmetric and Asymmetric Encryption in D365FO, exploring:

• How each encryption model works
• Real-world use cases
• Key management concepts
• Practical X++ examples
• Choosing the right approach for your integration scenarios

Stay tuned!