--- sourceDocument: Australia Platform security sourceDocumentLink: https://www.servicenow.com/docs/r/australia/platform-security Release : - australia ft:locale : - en-US ft:publication_title : - Australia Platform security ft:clusterId : - psec bundleId : - psec workflow : - Platform --- # Exploring Field Encryption # Exploring Field Encryption {#ariaid-title1} Release version: Australia Updated June 26, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of Exploring Field Encryption Field Encryption in ServiceNow Australia release provides robust encryption for data fields and attachments, ensuring sensitive information is protected from unauthorized access. It includes two editions: Field Encryption Starter and Field Encryption Enterprise, each with distinct capabilities and feature sets designed to secure data at the field level. Show full answer Show less By default, Field Encryption blocks all users, scripts, and system processes from accessing encrypted data. Access is controlled through a combination of Field Encryption Modules, Encrypted Field Configurations, and Module Access Policies (MAPs), which define authorized users or processes that can decrypt data. ## Access Control Mechanism Field Encryption access control works alongside Access Control Lists (ACLs) but is a separate mechanism that restricts encrypted data access strictly to authorized accessors. Multiple MAPs can be configured to enforce different access rules per encrypted field or group of fields. For example, one MAP can allow certain roles or scripts to access specific columns while blocking others. ## Differences Between Field Encryption Starter and Enterprise * **Field Encryption Starter:** Supports up to 5 encrypted fields, does not include attachment encryption or key management features, and requires ServiceNow Support for key rotation. * **Field Encryption Enterprise:** Offers unlimited encrypted fields and modules, supports attachment encryption, provides full key management within the instance, and supports customer-supplied keys (BYOK) and external key management services (HYOK). ## Key Roles for Configuration and Management * **KMF Admin and KMF Cryptographic Manager:** Responsible for configuring encryption modules, keys, encrypted field configurations, MAPs, and managing customer-supplied keys and Access Observer logs. * **KMF Cryptographic Operator:** Configures properties related to customer-supplied keys. ## Additional Important Information * Field Encryption does not track changes to encrypted fields in record history or activity streams. * Encryption of system tables (tables starting with `sys`) is not supported. * During cloning, encrypted data and modules are copied but require a key exchange to decrypt data on the target instance. Until then, encrypted fields appear unreadable, which is expected behavior. ## Next Steps for ServiceNow Customers To implement or manage Field Encryption, customers can explore configuration options and operational guidance through ServiceNow documentation on configuring Field Encryption and Field Encryption Enterprise. Enterprise edition requires a subscription and leverages the Key Management Framework (KMF) for advanced encryption management and key customization. Learn the details of Field Encryption Starter and Field Encryption Enterprise ## Encryption-backed access control {#exploring-fe__cf-exploring-parent-overview} By default, Field Encryption blocks all users, scripts, and system processes from accessing encrypted data. However, Field Encryption has an access control feature that works in combination with Access Control Lists (ACLs). This feature is also separate from ACLs and ensures only the correct users, scripts, or system processes can access encrypted data. You can configure Field Encryption access control feature through a combination of Field Encryption Modules, Encrypted Field Configurations, and Module Access Policies (MAPs). The next image shows how these three components work together. By default, encrypted data is locked down from all access. A MAP defines which accessor (users, scripts, and system processes) can be authorized to access the data. You can configure multiple MAPs to apply different access rules to different encrypted fields. In this diagram, Module Access Policy A covers columns A, B, C, and D. Module Access Policy B covers column E. Each policy has its own rules per accessor. Access rules can differ between two policies for each accessor type. The following table reflects the access rules defined for Module Access Policy A and Module Access Policy B. Module Access Policy A applies to columns A, B, C, and D. Module Access Policy B applies to column E. {#exploring-fe__cf-exploring-parent-overview__entry__3} | Accessor | MAP A Columns A, B, C, D | MAP B Column E | |-|-|-| | Role A | Allow | Block | | Role B | Allow | Block | | Role C | Block | Allow | | Script A | Allow | Block | | Script B | Block | Block | | Script C | Block | Allow | | System Context Processes | Block | Allow | [ ] ## Differences between Field Encryption Starter and Field Encryption Enterprise {#exploring-fe__section_bbm_xhn_b2c} The feature-set is different between Field Encryption Starter and Field Encryption Enterprise. {#exploring-fe__table_uk2_b3n_b2c__entry__3} | Feature | Field Encryption Starter | Field Encryption Enterprise | |-|-|-| | Number of encrypted fields | Up to 5 encrypted fields Note: Field Encryption Starter limits the number of encrypted fields, not encryption modules or contexts. Field Encryption replaces the deprecated Column Level Encryption product, which used a module and context-based limit. | No restriction on number of encrypted fields | | Attachment encryption | No | Yes | | Key management | None (Contact ServiceNow Support for key rotation) | Manage keys from your instance with no involvement from ServiceNow Support | | Supported data types | All supported data types | All supported data types | | Number of Field Encryption Modules | No restriction | No restriction | | Number of Module Access Policies | No restriction | No restriction | | Customer-Supplied Key (BYOK) | No | Yes | | External Key Management Service (HYOK) | No | Yes | [Table 1. Feature comparison: Field Encryption Starter vs. Enterprise] {#exploring-fe__table_uk2_b3n_b2c} ## Field Encryption users {#exploring-fe__cf-exploring-parent-users} {#exploring-fe__table_k3r_dhn_b2c__entry__2} | User | Description | |-|-| | Key Management Framework (KMF)Admin or KMF Cryptographic Manager | These roles are used to configure elements of Field Encryption. * Field Encryption modules and module keys * Cryptographic Specifications * Module life-cycle policies * Encrypted field configurations for fields and attachments * Module Access Policies (MAPs) * Configures, wraps, and uploads customer supplied keys (for Field Encryption Enterprise) * Configures Access Observer and review Access Observer logs. * Schedule mass encryption, decryption, or re-keying {#exploring-fe__ul_g1h_mvn_b2c} | | KMF Cryptographic Operator | Configures properties for customer supplied keys | [Table 2. Users] {#exploring-fe__table_k3r_dhn_b2c} ## Field Encryption and record history {#exploring-fe__section_pmv_bgy_q2c} Changes to fields encrypted with Field Encryption are not tracked in the activity stream for the record or in the record history `sys_history_set` table. ## Encryption on system tables {#exploring-fe__section_ph2_xjb_sgc} Field Encryption currently doesn't support the encryption of fields and attachments of system tables (system tables whose names begin with `sys_`). ## Cloning considerations {#exploring-fe__section_cloning_considerations} During cloning, encrypted field data and encryption modules are copied to the target instance. Encryption keys are re-encrypted with a secondary key unique to the source instance, so the target instance cannot decrypt the copied field data until key exchange completes. Until a key exchange is performed, encrypted fields on the cloned instance appear empty or unreadable. This is expected behavior and does not indicate data corruption or loss. To restore access to encrypted fields on the target instance, complete a key exchange from the source instance. See [Configure Key Exchange](https://www.servicenow.com/docs/2MshxOHs38q56vEGOExSEA "Key Management Framework (KMF) generates automatic key exchange requests for supported cryptographic modules during the fresh installation or upgrade of the instance, and manages the data encryption key locally for the instance."). ## What to explore next {#exploring-fe__cf-exploring-parent-links} To learn more about configuring and using Field Encryption, see: * [Configuring Field Encryption](https://www.servicenow.com/docs/pAE0xCeXpfmGyz8PY3LgdQ "Learn how to activate and configure Field Encryption and manage migration from Encryption Support.") * [Using Field Encryption](https://www.servicenow.com/docs/a8EZORmhNQJej08G_T9Q9g "Use Field Encryption to manage access to encrypted data on your instances.") {#exploring-fe__ul_o3r_dhn_b2c} * **[Field Encryption Enterprise](https://www.servicenow.com/docs/W1Wx_FNFmsTlXZLAGAQLMw)** Field Encryption Enterprise uses the Key Management Framework (KMF) to enable you to customize and manage how fields and attachments are encrypted and decrypted on your instance. A subscription is required to use Field Encryption Enterprise.