Edge Encryption

What It Is

Edge Encryption encrypts sensitive field data on the customer's premises before it's transmitted to the ServiceNow cloud instance, ensuring ServiceNow cannot access the plaintext values of protected fields. The feature operates through an on-premises encryption agent that intercepts data before it reaches ServiceNow servers, encrypting specified fields using customer-managed keys. This creates a zero-knowledge architecture where ServiceNow can store and process encrypted data without ever having access to the decryption keys or plaintext values. The encrypted data remains searchable and reportable through special encrypted search capabilities, but the actual sensitive content stays protected even from ServiceNow personnel and platform processes.

Architecturally, Edge Encryption lives in the Security Operations application within the Data Protection module. It operates at the transport layer between the ServiceNow client interface and the platform's database layer, intercepting form submissions, imports, and API calls before they reach the instance. The configuration exists both in the cloud instance (field configuration and policies) and on-premises (encryption agent and key management). This dual-layer approach means you're managing both cloud-side field definitions and premise-based encryption infrastructure simultaneously.

The feature integrates directly with ServiceNow's data model through field-level encryption policies that attach to specific table columns. When you mark a field for edge encryption, ServiceNow creates corresponding encrypted field storage and maintains metadata about encryption status, but the actual encryption and decryption operations happen outside the platform. The system maintains referential integrity and supports workflow operations on encrypted fields, but with significant limitations on field operations like calculated fields, derived values, and certain reporting functions.

You cannot function without Edge Encryption when regulatory compliance requires that third-party cloud providers never have access to sensitive data in plaintext form. Healthcare organizations handling PHI under HIPAA, financial institutions with PCI DSS requirements for cardholder data, or government agencies with classified information processing mandates typically require this level of data protection. Traditional ServiceNow field encryption isn't sufficient for these scenarios because ServiceNow still processes and can potentially access the encrypted data during platform operations. Edge Encryption is also essential when customer contracts or data sovereignty requirements explicitly prohibit cloud providers from having decryption capabilities for sensitive business data.

Platform owners manage the overall Edge Encryption strategy and infrastructure deployment, including the on-premises agent installation and key management policies. ServiceNow administrators handle the cloud-side configuration, defining which fields get encrypted and managing the encryption policies within the instance. Developers need to understand Edge Encryption's limitations when building applications, as encrypted fields behave differently in business rules, client scripts, and integrations. The relationship between these roles is critical because Edge Encryption decisions affect both infrastructure architecture and application development patterns throughout the ServiceNow implementation.

Recent ServiceNow releases have enhanced Edge Encryption's integration with Now Platform capabilities, particularly around encrypted field search and reporting in Vancouver and later releases. The Xanadu release introduced improved performance for encrypted field operations and better support for bulk data operations with encrypted fields. Key changes include enhanced encrypted search capabilities that maintain better performance at scale and improved integration with ServiceNow's analytics and reporting tools, though significant limitations remain for complex field operations and cross-table relationships involving encrypted data.

Where to Find and Configure It

Navigate to Security Operations > Data Protection > Edge Encryption for the primary configuration interface where you define encryption policies and manage encrypted field definitions. Access System Definition > Dictionary to configure individual field encryption settings on specific table columns. The sys_dictionary table contains the edge_encryption_enabled field that controls per-field encryption activation.

Monitor encrypted field operations at Security Operations > Data Protection > Edge Encryption > Encryption Status to view encryption agent connectivity and field encryption status. Check System Logs > System Log > Edge Encryption for encryption operation logs and troubleshooting information. View encrypted data in action by examining any table with encrypted fields enabled - the encrypted values appear as encoded strings while the on-premises agent handles decryption for authorized users.

How It Works Step by Step

Edge Encryption operates through a client-side encryption agent that intercepts data before it leaves the customer's network boundary. When a user submits a form containing encrypted fields, the encryption agent captures the submission, encrypts the designated field values using customer-managed keys, and then forwards the encrypted payload to ServiceNow. The ServiceNow instance receives and stores only the encrypted values, maintaining complete ignorance of the plaintext content. For data retrieval, the process reverses: ServiceNow returns encrypted values to the customer's network, where the edge agent decrypts them before presenting the plaintext to authorized users.

The encryption process integrates with ServiceNow's standard data validation and processing pipeline, but with critical timing differences. Field validation, business rules, and workflow operations that depend on plaintext field values must be configured to work with encrypted data or moved to pre-encryption processing stages. The system maintains encrypted field metadata and indexing capabilities to support search and reporting functions, but with significant performance and functionality limitations compared to standard plaintext field operations.

The Encryption Pipeline

1. User submits form data or API call containing fields marked for edge encryption
2. Edge encryption agent intercepts the data payload before network transmission
3. Agent identifies encrypted fields based on field configuration policies
4. Customer-managed encryption keys encrypt the designated field values
5. Encrypted payload transmits to ServiceNow instance with original form structure intact
6. ServiceNow processes and stores encrypted values without decryption capability
7. For retrieval, ServiceNow returns encrypted values to customer network
8. Edge agent decrypts values before presenting to authorized users

// Business rule to handle encrypted field logic
(function executeRule(current, previous) {
    // Check if field is edge encrypted before processing
    var fieldName = 'u_sensitive_data';
    var dictionary = new GlideRecord('sys_dictionary');
    dictionary.addQuery('name', current.getTableName());
    dictionary.addQuery('element', fieldName);
    dictionary.query();
    
    if (dictionary.next() && dictionary.edge_encryption_enabled == 'true') {
        // Handle encrypted field - limited operations available
        gs.log('Processing encrypted field: ' + fieldName);
        // Cannot perform string operations or comparisons on encrypted values
        // Use encrypted field search capabilities instead
    } else {
        // Standard field processing
        current[fieldName] = current[fieldName].toUpperCase();
    }
})(current, previous);

Real-World Scenarios

Encrypting Patient Information in Healthcare Service Management

A healthcare organization needs to store patient medical record numbers and diagnosis codes in ServiceNow incident tickets while maintaining HIPAA compliance. The requirement mandates that ServiceNow never has access to plaintext PHI, but support staff must be able to search and reference this information during case resolution.

Navigate to System Definition > Dictionary and locate the incident table fields u_patient_mrn and u_diagnosis_code. Set edge_encryption_enabled=true on both fields. Configure the edge encryption policy at Security Operations > Data Protection > Edge Encryption to include the incident table and specified fields. Deploy the edge encryption agent on the customer's network with healthcare-compliant key management integration.

Watch for business rules and workflows that reference these fields - they'll receive encrypted values and fail on string operations or conditional logic. Encrypted field search requires special configuration and performs differently than standard field searches. Any integration pulling incident data will receive encrypted values unless the integration endpoint is within the customer's encrypted network boundary.

Protecting Credit Card Data in Financial Services Requests

A financial services company processes customer requests that include partial credit card numbers and account identifiers for verification purposes. PCI DSS compliance requires that cardholder data never exists in plaintext within third-party cloud environments, but customer service representatives need to reference this information during request processing.

// Configure PCI-sensitive fields for edge encryption
var gr = new GlideRecord('sys_dictionary');
gr.addQuery('name', 'x_company_requests');
gr.addQuery('element', 'IN', 'u_card_last_four,u_account_number,u_routing_info');
gr.query();

while (gr.next()) {
    gr.edge_encryption_enabled = 'true';
    gr.encrypted_search_enabled = 'true';
    gr.update();
    gs.log('Enabled edge encryption for PCI field: ' + gr.element);
}

// Create encryption policy for financial data
var policy = new GlideRecord('sys_edge_encryption_policy');
policy.name = 'PCI Cardholder Data Protection';
policy.table = 'x_company_requests';
policy.active = 'true';
policy.insert();

Ensure your edge encryption agent has proper PCI-compliant key management and audit logging enabled. Test encrypted field search capabilities thoroughly as performance degrades significantly with large datasets. Configure role-based access controls carefully since encrypted fields require different permission models than standard fields - users need both field access rights and edge decryption permissions.

Government Classification Data in Security Incident Response

A government agency uses ServiceNow for security incident response but needs to include classified threat intelligence and asset details in incident records. Federal compliance requires that classified information never exists in plaintext outside government-controlled infrastructure, while maintaining the ability to search and correlate threat data across incidents.

Create custom fields on the security incident table for u_threat_indicators, u_classified_assets, and u_intelligence_sources with edge encryption enabled. Configure the edge encryption policy to require government-certified encryption standards and key management through the agency's existing classification infrastructure. Set up encrypted search capabilities with performance tuning for large-scale threat intelligence correlations.

Government edge encryption requires additional audit logging and access controls beyond standard enterprise implementations. Verify that your encryption agent meets federal security standards and integrates properly with existing classified network infrastructure. Monitor performance closely as encrypted field operations can significantly impact incident response workflows during high-volume security events.

The Classic Mistake

// BAD: This business rule breaks after enabling Edge Encryption on u_ssn
(function executeRule(current, previous /*null when async*/) {
    
    // This comparison will always fail - encrypted field returns gibberish
    if (current.u_ssn.toString().length != 9) {
        gs.addErrorMessage('SSN must be 9 digits');
        current.setAbortAction(true);
    }
    
    // This query will never find matches
    var existing = new GlideRecord('sys_user');
    existing.addQuery('u_ssn', current.u_ssn);
    existing.query();
    
    if (existing.next()) {
        gs.addErrorMessage('SSN already exists in system');
        current.setAbortAction(true);
    }
    
})(current, previous);

This fails because Edge Encryption makes encrypted field values completely unreadable to server-side scripts. The business rule sees encrypted gibberish like $crypto$AES256$... instead of the actual SSN, so length checks fail and duplicate detection becomes impossible. Users see cryptic validation errors that make no sense, and data integrity rules silently break. The mistake is non-obvious because the field appears to save successfully—the encryption itself works perfectly, but all the business logic depending on that field's value stops functioning.

// GOOD: Validate format client-side, use display value for server logic
(function executeRule(current, previous /*null when async*/) {
    
    // Move format validation to client script - can access decrypted value
    // Server-side: focus on business logic that doesn't need the raw value
    
    // Use a separate, non-encrypted field for duplicate checking
    if (current.u_ssn_hash && current.u_ssn_hash.changes()) {
        var existing = new GlideRecord('sys_user');
        existing.addQuery('u_ssn_hash', current.u_ssn_hash);
        existing.addQuery('sys_id', '!=', current.sys_id);
        existing.query();
        
        if (existing.next()) {
            gs.addErrorMessage('SSN already exists in system');
            current.setAbortAction(true);
        }
    }
    
})(current, previous);

When to Use This vs Alternatives

Edge Encryption is the right choice when you need to store highly sensitive data that even ServiceNow support should never be able to read, and your compliance requirements explicitly mandate client-side encryption. Use it for PII like SSNs, credit card numbers, or medical data where regulatory frameworks require the service provider to have zero access to plaintext values.

When Edge Encryption is Correct

Choose Edge Encryption when compliance auditors specifically require that the cloud provider cannot access sensitive data in any circumstance, including support scenarios. Standard ServiceNow field encryption and column-level encryption still allow ServiceNow personnel to potentially decrypt data during support cases. Edge Encryption is also necessary when data sovereignty laws require that decryption keys never leave your geographic region, since the keys remain on your Edge Encryption servers.

When to Use Alternatives Instead

Use standard field encryption for most sensitive data scenarios where you still need server-side business logic to process the values—workflows, business rules, and integrations can still access decrypted data. Choose column-level encryption when you need reporting and querying capabilities on sensitive fields, since Edge Encryption makes these impossible. For password storage, use the built-in Password2 field type instead of any encryption method.

When You Need Both Together

Combine Edge Encryption with hash fields when you need both absolute security and business functionality—store the sensitive value in an Edge Encrypted field and a SHA-256 hash in a separate field for duplicate detection and basic business rules. Use Edge Encryption alongside Data Loss Prevention (DLP) policies to ensure sensitive data gets encrypted automatically when users paste it into form fields. This combination provides defense in depth for the most critical data.

Platform Interactions & Side Effects

• Business Rules and Script Includes see encrypted values as $crypto$AES256$[base64data] strings, breaking any logic that depends on actual field content
• Notifications and email templates display encrypted gibberish unless configured to use ${field.getDisplayValue()} which shows asterisks
• Update Sets capture the edge_encryption_enabled attribute on sys_dictionary records but cannot migrate data between instances
• ACL conditions fail when testing encrypted field values, since current.field == 'value' always returns false
• Audit records in sys_audit show encrypted values in oldvalue and newvalue fields, making audit trails unreadable
• Import sets and transform maps write encrypted values directly to staging tables, requiring client-side data preparation before import
• REST API responses return encrypted strings unless you set sysparm_display_value=all which shows masked values
• List views show asterisks for encrypted fields, and sorting/filtering on these columns becomes meaningless since it operates on encrypted data
• Performance degrades on queries with addQuery() conditions on encrypted fields since the database cannot use indexes effectively
• Reference qualifiers and dependent field logic break when referencing encrypted field values, causing dynamic filter conditions to fail silently

Debugging and Troubleshooting

The most common failure symptom is business rules and workflows suddenly behaving erratically after enabling Edge Encryption—validation rules fail unexpectedly, duplicate detection stops working, and automated processes skip records they should process. Users see form validation errors that reference field values as "$crypto$AES256$..." in error messages, and administrators notice that server-side scripts log warnings about string comparison failures. Client-side symptoms include fields that appear to save successfully but cause subsequent form operations to fail validation.

Check System Logs > All for JavaScript errors containing encrypted field references, and examine sys_dictionary records where edge_encryption_enabled=true to identify affected fields. The Edge Encryption status appears in System Definition > Edge Encryption Status, and connection issues generate entries in System Logs > Edge Encryption with specific error codes.

Look for error messages like "Cannot read property of encrypted value" in script execution details, and "Edge Encryption server unreachable" in the Edge Encryption logs. Debug output shows "[object Object]" or "$crypto$" prefixed strings when scripts incorrectly attempt to process encrypted field values. Network connectivity issues appear as "Connection timeout to encryption server" errors with specific IP addresses and port numbers in the logs.

Diagnostic Checklist:

• Verify Edge Encryption server connectivity from System Definition > Edge Encryption Status shows "Connected" status
• Check sys_properties for correct glide.edge_encryption.server_url and certificate settings
• Review all business rules and workflows that reference encrypted fields for script modifications
• Test field encryption/decryption with a simple form save and verify client-side values appear correctly
• Examine sys_dictionary.edge_encryption_enabled flag matches your intended configuration
• Validate firewall rules allow HTTPS traffic on port 443 to your Edge Encryption server
• Check if user roles include edge_encryption_admin for configuration access and edge_encryption_user for field access

Quick Reference

• Maximum field length for Edge Encryption is 4,000 characters—longer values get truncated silently during encryption
• Encrypted field queries using addQuery('field', 'CONTAINS', 'value') never return results—the database searches encrypted strings
• Edge Encryption requires the com.snc.encryption.edge plugin activated and consumes additional licensing costs
• Reference fields cannot be Edge Encrypted—only string, text area, and journal fields support encryption
• Choice fields lose their dropdown functionality when Edge Encrypted—users must type values manually
• Import Set runs fail when source data contains unencrypted values for Edge Encrypted destination fields
• Clone operations copy encrypted values as-is, requiring re-encryption if keys differ between source and target instances
• Background script access to encrypted fields via gs.print(gr.field) shows encrypted strings, never decrypted values
• Performance Analytics and Reporting cannot aggregate or analyze Edge Encrypted fields meaningfully
• Mobile app users see encrypted strings in offline mode when the Edge Encryption server is unreachable