Module access policy debugger

Release version: Australia

Updated March 12, 2026

2 minutes to read

Summarize

Summarized using AI

Summary of Module Access Policy Debugger

The Module Access Policy Debugger is a tool that helps you understand access issues related to cryptographic modules by reviewing logging information. It allows you to see which module access policies (MAPs) are evaluated when a user or script attempts to access a cryptographic module for encryption or decryption. This understanding is crucial for ensuring that users are granted the appropriate access to encryption contexts.

Show full answer Show less

Key Features

Logging Information: Displays detailed logs to help identify why access is granted or denied.
Access Control: Access to debug logs is role-based, with specific roles (snkmf.admin and snkmf.cryptographicmanager) having default access.
Debugger Management: You can enable or disable debug logging through the navigation settings.
Impersonation: Facilitates troubleshooting by allowing you to view debug logs from the perspective of other users, provided the necessary impersonation settings are enabled.

Key Outcomes

By utilizing the Module Access Policy Debugger, you can effectively troubleshoot access issues, understand the evaluation process of MAPs, and ensure that users have the necessary permissions to perform encryption and decryption tasks. This tool enhances your ability to manage cryptographic access and maintain security compliance within your ServiceNow instance.

Use the module access policy debugger to review logging information and understand why your users are or aren’t granted access to an encryption context.

Module access policies (MAPs) define instance-level controls for access to cryptographic modules. Callers (for example, a user or script) require explicit access to use a cryptographic module for encryption and decryption. Use the debugger to see which policies are evaluated when a caller attempts to access a cryptographic module. You can also use the debugger and learn why access is or isn’t being granted.

This flowchart shows how your instance evaluates requests for access to a cryptographic module.

Flowchart showing the how access to cryptographic modules are evaluated

Control access to the debug logs

Access to the module access debug logs is determined by role. Users with the sn_kmf.admin and sn_kmf.cryptographic_manager roles have access to the debugger. Grant access to other roles using the glide.kmf.module_access_policies.debugger.authorized.roles system property. The value of this property is a comma-separated list of roles that access the debug logs.

Enable or disable the debugger

To enable debug logging messages for module access policies, navigate to All > Diagnostics > Session Debug > Debug Module Access Policies > .

When you’re finished debugging, you can disable the logging messages by navigating to All > Diagnostics > Session Debug > Disable All > .

Access the logs

After enabling debugging, navigate to a page that triggers a MAP evaluation to view the MAP debug logs. Debug messages appear at the bottom of the page.

Tip:

You can use impersonation to troubleshoot access for other users. For details on impersonation, see Impersonating users. To view the debug logs from the perspective of another user, make sure that your module access policies with the role type have the Impersonation field set as true.

In this example, a caller invokes two access requests to the global.fuji cryptographic module. A symmetric encryption, which is granted, and a symmetric decryption, which was denied.

Understanding log entries

Debugging information is structured using this format.

This first line displays the cryptographic module receiving the access request.
The lines between the first and last line displays the evaluated MAPs in the order that they were evaluated, and includes their name, type, target, granular operation, and result.
The last line displays the Policy Decision (if applicable) and the net access result for the caller (whether the caller is granted access).

Each line starts with an icon that indicates its message type.

Table 1. Message icons
Icon	Message type
	Informational message
	Module access policy grants access
	Module access policy denies access
	Caller is granted access
	Caller is denied access
	No module access policy to evaluate

Debug log examples

Access granted message
Access denied message
Access denied (No module access policies to evaluate
Access denied (insufficient privileges)