---
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


---

# Create a user module access policy

# Create a user module access policy {#ariaid-title1}

Release version: Australia  
Updated April 28, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 1 minute to read  
Create a module access policy (MAP) for a matched user to encrypt attachments when inbound email processing runs as that user.

## Before you begin

Role required: admin

## About this task

These instructions create a role-based MAP for the matched user. A role-based MAP requires impersonation to be enabled so that the user has access to the cryptographic module. Other MAP types, such as script or scope, can
also be used to grant the user access to the cryptographic module, but don't include an impersonation option. See [Configure module access policies for Field Encryption](https://www.servicenow.com/docs/L0MjtiANQnF1Edd4YjUNpQ "Create a module access policy to control which users, scripts, or system processes can encrypt or decrypt data encrypted by a field encryption module.") for information on all available MAP types.

## Procedure

1. Navigate to AllSystem SecurityField EncryptionField Encryption Experience.
2. Select Access Policies in the tile of the module configured for the target table's encryption configuration.
3. Select Create new.
4. Enter a name for your MAP in the Policy name field.
5. Select Role in the Type field.
6. In the Target role field, select the role of the user that the attachment transfer process impersonates.
7. Select Impersonation so that the MAP enables access when that user is impersonated.
8. Fill out the rest of the form accordingly.  
9. Select Save.

## Result

The user MAP has been created.

**Encrypted attachments and missing metadata**

When you encrypt an attachment, the hash and state fields on the sys_attachment record aren't populated. This is by design.

The hash field stores a SHA-256 fingerprint of an attachment's content. Even though a file is encrypted, a hash is a deterministic and stable identifier. The same file produces an identical hash value. Storing the hash would enable an attacker who has a copy of the file to confirm that it exists in your system and can weaken encryption.

Because of this, duplicate detection doesn't work for encrypted attachments, since ServiceNow uses the hash field to prevent identical attachments from being added to a record.

*[\>]: and then