Release changes · Australia → Brazil

ServiceNow Brazil release: new security properties and default changes

We compared the official ServiceNow documentation of the Australia and Brazil releases property by property. This page lists the system properties whose documented default value changed and the security properties that show up in the Brazil docs for the first time, with what they do, ServiceNow's recommended value and what to check before or after your upgrade.

By Sören MaucherUpdated 2026-10-24Source: ServiceNow Australia and Brazil product documentation

59security properties newly documented

7where ServiceNow recommends a non-default value

4documented defaults changed or corrected

214properties mentioned for the first time

New in the docs does not always mean new in the platform. Many of these properties existed before Brazil and are simply documented for the first time, often in the security hardening guide. They are still worth checking for impact, because the docs now describe a recommended value and what happens if it is set differently.

Defaults on this page are the values the documentation states. On an upgraded instance, existing property records usually keep their current value, so always check what your instance actually has.

Spotted a mistake, or know how one of these behaves after the upgrade? Send me a message and I will update the page.

Changed default values

Properties that both releases document, but with a different default value. We compared every property reference table in the two documentation sets and removed formatting differences, so what is left are real changes, corrections and one conflict inside the Brazil docs.

`glide.discovery.certs.enable_incident_creation_for_expired_certificates`

Default changedCertificate Inventory and Management (ITOM)

Australia: true Brazil: false

The scheduled job of Certificate Inventory and Management creates incidents for expired certificates, meaning certificates whose validity is past the current date. The Australia docs list the default as true and add "By default, this property is enabled". The Brazil docs list false and drop that sentence.

What to check: If your team relies on automatic incidents for expired certificates, open sys_properties.list on the instance and confirm the value is still true after the upgrade. Teams that found these incidents noisy can leave it at false.

ServiceNow docs: Customize Certificate Inventory and Management ↗

`work.management.travel.time.threshold.minutes`

Default changedField Service Management, Dynamic Scheduling

Australia: 5 Brazil: 0

Sets the travel time in minutes within which dynamic scheduling assigns a work order task to the nearest agent. The documented default drops from 5 to 0. The Brazil docs also add where to find it: Field Service > Dynamic Scheduling Administration > Properties.

What to check: If you use Dynamic Scheduling, compare the value on your instance with what your dispatch process expects and test agent assignment for nearby work orders.

ServiceNow docs: System properties ↗

`password_reset.wf.timeout`

Docs conflictPassword Reset

Australia: 90000 (milliseconds) Brazil: 500 (milliseconds) or 90000

The maximum time in milliseconds the password reset workflow may take after the user selects Submit. The Brazil Platform Administration book now lists a default of 500 milliseconds, while the ServiceNow Platform book still says 90000. Australia only listed 90000.

What to check: Do not change anything because of the docs alone. Check the value on your instance, and if password resets time out after the upgrade, this is the first property to look at.

ServiceNow docs: Available system properties ↗

`glide.ui.mentions.default_limit`

Docs correctedActivity Stream, @mentions

Australia: true (type string) Brazil: 5 (type integer)

Number of users with the same name that the Activity Stream compose editor shows when you @mention someone. The Australia docs described it as a string with the default true, which did not fit a limit. Brazil documents it as an integer with the default 5.

What to check: Nothing to do unless you changed it. If your instance holds a non-numeric value, set a number.

ServiceNow docs: Available system properties ↗

New security properties in Brazil

These 59 properties appear in the Brazil documentation but not in Australia. Most come from the instance security hardening guide, which states a recommended value, the default and a risk score for each setting. Risk scores are ServiceNow's CVSS-style severity for a wrong value, not a rating of the property itself.

Recommended value differs from default (7)

Start here. For these settings the docs recommend a value other than the documented default, so an instance that was never touched is not in the recommended state.

Property	Default	Recommended	Risk
`glide.authenticate.basic_auth.restriction.default_decision`	`Maintain current login-Basic Auth API and UI login allowed`	`Revoke Basic Auth API login-Basic Auth API login blocked; UI login allowed`	High 8.1
`glide.authenticate.basic_auth.allow_snc_external`	`true`	`false`	High 8.1
`com.glide.script.sandbox.ks.watchdog.phase`	`0`	`3`	High 8
`com.glide.script.static_analysis.enable_sync`	`false`	`true`	Medium 6.8
`com.snc.platform.security.oauth.mcp.aig_scope_support`	`false`	`true`	Medium 4.3
`com.glide.hub.code_signing.full.validation.enabled`	`false`	`true`	Medium 4.4
`glide.cs.sanitize_inbound_messages.enabled`	`false`	`true`	Low 3.5

Basic authentication restriction (6)

The biggest new block in the Brazil docs is the basic authentication restriction gate. It looks at inbound API requests that use basic auth (username and password) from accounts that also log in interactively. Those requests skip the multi-factor authentication the same account would need in the browser, so a stolen password works directly against the API.

According to the docs, the gate starts in tracking mode the first time glide.authenticate.basic_auth.restriction.active is true. Basic-auth requests are recorded in the sys_user_basic_auth_exception table for admins to review, and actual blocking only starts once enforcement is switched on. Accounts first detected during tracking get the default decision, which is Maintain current login. ServiceNow recommends Revoke Basic Auth API login, which blocks basic auth on the API but keeps UI login.

List the integrations that call your instance with basic auth and a normal user account.
Review the Basic Auth Exception table before enforcement starts.
Move integrations to OAuth or dedicated web service access only accounts where you can.
Decide whether external users (snc_external) really need the exemption.

Property	Default	Recommended	Risk	What it does
`glide.authenticate.basic_auth.restriction.active` true \| false	`true`	`true`	High 8.1	This property determines whether the platform evaluates inbound basic-auth API requests against allowed access paths, impacting security enforcement. ServiceNow docs: Enable basic authentication restriction ↗
`glide.authenticate.basic_auth.restriction.enforce` true \| false	`false`	Not stated	-	This property enables or disables the enforcement of Basic Authentication restrictions, blocking requests from non-allow-listed accounts when active.
`glide.authenticate.basic_auth.restriction.default_decision` choice list	`Maintain current login-Basic Auth API and UI login allowed`	`Revoke Basic Auth API login-Basic Auth API login blocked; UI login allowed`	High 8.1	This property defines the default decision for basic-auth accounts, allowing for either unrestricted access or imposing restrictions based on the specified choice. ServiceNow docs: Set basic authentication restriction default decision ↗
`glide.authenticate.basic_auth.allowed_roles` string	`snc_basic_auth_api_access`	`snc_basic_auth_api_access`	High 8.1	This property defines a comma-separated list of roles that can authenticate via basic auth without multi-factor authentication, impacting security protocols. ServiceNow docs: Limit basic authentication restriction allowed roles ↗
`glide.authenticate.basic_auth.allowed_users` string	Not stated	`<Empty> or limited to specific, individually-reviewed dedicated service accounts`	High 8.1	This property contains a comma-separated list of user sys_ids that are allowed to bypass the Basic Authentication Restriction gate, enabling them to authenticate without multi-factor authentication. ServiceNow docs: Limit basic authentication restriction allowed users ↗
`glide.authenticate.basic_auth.allow_snc_external` true \| false	`true`	`false`	High 8.1	This property determines whether users with the snc_external role can bypass basic authentication restrictions, impacting their access to the system. ServiceNow docs: Restrict basic authentication external role exemption ↗

Script sandbox and static analysis (KittyScript) (8)

Brazil documents the KittyScript sandbox of the Guarded Scripts framework. It runs scripts from untrusted scopes, guest sessions and dynamic evaluation (for example reference qualifiers and scripted default values) in a restricted interpreter so they cannot run with full system privileges.

Enforcement for authenticated traffic moves through phases, from detection only to full rejection of incompatible scripts. The docs list the defaults as enabled, auto advance on, 14 days per phase and phase 0, and recommend phase 3. Static analysis gets three properties of its own: whether it also checks authenticated users, and whether violations block a script right away (synchronous) or are only logged.

Check the Incompatible Guarded Scripts list for scripts the sandbox flagged.
Test guest-facing features that evaluate scripts: reference qualifiers, scripted default values, public pages.
Before turning on static analysis for authenticated users, test critical business rules, script includes and scheduled jobs. The docs mention patterns like Array.prototype access as typical findings.
Do not edit the phase property by hand. The docs point to the GlideGuardedScript script include for moving between phases.

Property	Default	Recommended	Risk	What it does
`com.glide.script.sandbox.ks.watchdog.enabled` true \| false	`true`	`true`	High 8	This property determines whether KittyScript is enabled for all transactions, with a default setting that ensures enhanced security by allowing only trusted scripts to run. ServiceNow docs: Enable KittyScript sandbox security enforcement ↗
`com.glide.script.sandbox.ks.watchdog.phase` string	`0`	`3`	High 8	It defines the enforcement phase for the guarded script evaluator, impacting how untrusted scripts are handled and restricted within the system. ServiceNow docs: Enable KittyScript sandbox security enforcement ↗
`com.glide.script.sandbox.ks.watchdog.auto.advance` string	`true`	`true`	High 8	This property controls whether the system automatically transitions between enforcement phases for guarded scripts based on a specified duration, enhancing security over time. ServiceNow docs: Enable KittyScript sandbox security enforcement ↗
`com.glide.script.sandbox.ks.watchdog.phase.duration.days` integer	`14`	`14`	High 8	It specifies how long each phase of the KittyScript watchdog remains active before advancing to the next phase, with a default duration of 14 days. ServiceNow docs: Enable KittyScript sandbox security enforcement ↗
`com.glide.script.kittyscript.validation.mode` string	`block`	`block`	Critical 9.1	This property enforces validation rules for guest user scripts, blocking unauthorized operations and syntax to prevent security vulnerabilities. ServiceNow docs: Enforce KittyScript validation for guest sessions ↗
`com.glide.script.static_analysis.disabled`	`false`	`false`	Medium 6.8	This property, when set to false, enables static analysis for scripts run by authenticated users, helping to identify security issues during execution. ServiceNow docs: Enable static analysis ↗
`com.glide.script.static_analysis.enable_sync`	`false`	`true`	Medium 6.8	This property determines whether static analysis violations block script execution immediately or are logged for review without interruption. ServiceNow docs: Enable synchronous mode for static analysis ↗
`com.glide.script.static_analysis.only_check_unauthenticated_users`	`false`	`false`	Medium 6.8	This property configures static analysis to include scripts from authenticated users, enhancing security by detecting potentially malicious code executed by all user types. ServiceNow docs: Apply static analysis to all users ↗

Scripting governance (3)

With scripting governance on, only users with the script-writer role can create or change records that contain executable script: business rules, email templates, conditions, workflows and HTML or XML content. The docs call it a foundational control and say the property should either not exist or be true.

So that nobody loses access, a one-time job after the Zurich upgrade adds all eligible users to the Conditional Script Writer group, and a weekly job keeps that group up to date afterwards.

Check the members of the Conditional Script Writer group after the upgrade.
Make sure integration and import users that write script fields still have the role they need.

Property	Default	Recommended	Risk	What it does
`glide.security.scripting_governance.enabled` true \| false	`true`	`true`	Medium 4.3	This property restricts script authorship to authorized users, ensuring that only those with the script-writer role can create or modify executable script content across the platform. ServiceNow docs: Restrict script authorship to authorized users only ↗
`glide.security.scripting_role.auto_provisioning` true \| false	`true`	Not stated	-	This property determines whether a scheduled job runs to automatically update group memberships for the Conditional Script Writer group based on user eligibility. ServiceNow docs: Explore Scripting Governance Tool ↗
`glide.security.scripting_role.provisioning_job_running` true \| false	`false`	Not stated	-	This boolean property tracks the status of the initial provisioning job for Scripting Governance, affecting user group memberships. ServiceNow docs: Manage Scripting Governance Tool ↗

Cross-scope dot-walking (3)

These properties control access checks when a script dot-walks into a table of another application scope. When enforcement is on, authorization is checked for all cross-scope table access through dot-walking, unless a table sets the enforce_dot_walk_cross_scope_access dictionary attribute to false. A log-and-allow mode records violations without blocking them and overrides the enforcement property. ServiceNow describes the change in KB2793170 (Dot-Walk Scoping Security Enhancement).

Search the system log for dot-walk violation messages before you switch off log-and-allow mode.
Test scoped apps that read data from other scopes through reference fields.

Property	Default	Recommended	Risk	What it does
`glide.script.dot_walk.enforce_cross_scope_access_all_tables` true \| false	`true`	`true`	-	This property determines whether authorization checks are enforced for all cross-scope table data accesses through dot-walking, unless overridden by specific table settings. ServiceNow docs: Enforce cross-scope table access when performing dot-walk ↗
`glide.script.dot_walk.log_and_allow_violations`	`false`	`false`	Medium 6.4	This property enables logging of access violations when dot-walk is used to access tables across application scopes without enforcing access controls. ServiceNow docs: Disable log-and-allow mode for cross-scope dot-walk access ↗
`glide.script.dot_walk.log_stack_trace_when_blocked` true \| false	`true`	Not stated	-	When dot-walk access to a protected table is blocked, this property determines whether the informational log message includes a full stack trace. ServiceNow docs: Available system properties ↗

ACLs, CSRF and REST access policies (6)

A group of access control settings that tighten edge cases. ACLs that only reference deleted roles are denied instead of falling back to default logic, roleless scripted ACLs no longer grant access to unauthenticated users, and CSRF token checks extend to authenticated processors and session-authenticated public REST APIs. A separate allowlist lets specific processors skip the new CSRF check.

Look for ACLs that reference roles you deleted, for example after uninstalling an app. The system log names them when strict deny blocks access.
Test custom processors and UI pages that post to the instance. Add a processor to the allowlist only if it cannot send a CSRF token.

Property	Default	Recommended	Risk	What it does
`glide.security.acl_with_invalid_roles_strict_deny` true \| false	`true`	`true`	Medium 5.1	This property enforces strict denial of access for ACLs that reference only deleted or non-existent roles, preventing unauthorized access based on misconfigured role references. ServiceNow docs: Enforce strict deny for ACLs referencing only deleted or non-existent roles ↗
`glide.security.allow_unauth_roleless_acl`	`false`	`false`	High 7.5	This property controls access for unauthenticated users to resources governed by roleless scripted Access Control Lists, impacting system security. ServiceNow docs: Prevent unauthenticated roleless ACL in scripted ACLs ↗
`glide.security.csrf.processor.all.authenticated.enabled`	Not stated	Not stated	-	This property enforces CSRF token validation for authenticated requests, rejecting those without valid tokens to protect against CSRF attacks. ServiceNow docs: Enable CSRF enforcement for authenticated processors ↗
`glide.security.csrf.httpauth_processor_allowlist` string	Not stated	Not stated	-	This property allows specified processors to bypass CSRF enforcement when the broader CSRF checks for authenticated requests are enabled, preventing HTTP 401 rejections for those processors. ServiceNow docs: Enable CSRF enforcement for authenticated processors ↗
`glide.security.csrf.rest.public_csrf.enabled` true \| false	`true`	`true`	Medium 4.3	This property enforces CSRF token validation for public REST API requests, requiring a valid token to prevent CSRF attacks. ServiceNow docs: CSRF enforcement for session-authenticated REST APIs ↗
`glide.rest.policy.normalize_apply_all_fields` true \| false	`true`	`true`	Medium 6.5	It normalizes the generation of lookup keys for REST API access policies by discarding specific values when wildcard flags are set, ensuring policies match their declared scope. ServiceNow docs: Normalise REST API access policy key generation ↗

New or newly documented settings around how users and apps sign in: the policy-based (identifier-first) login experience, Soft PIN enrollment, mutual authentication (which the new ATF health checks expect for Cloud Runner), a cap on the effective session timeout, JWT verification for guest embedded sessions, CORS origins for the OAuth endpoints and least-privilege scopes for MCP OAuth tokens.

If you raised the session timeout above 1440 minutes, expect it to be capped.
Browser apps that call the OAuth endpoints from another domain need their origin in the CORS property.
If you expose MCP or AI agent endpoints with OAuth, check the token scope settings.

Property	Default	Recommended	Risk	What it does
`glide.authenticate.policy_based_login_experience.enabled` true \| false	`true`	Not stated	-	This property activates the policy-based login experience, allowing the creation and management of identifier-first login policies that dictate user authentication methods. ServiceNow docs: Activate the policy-based login experience ↗
`glide.auth_factors.softpin.enrollment.enabled` true \| false	`false`	Not stated	-	This property controls the display of the Soft PIN enrollment option, affecting user access to enroll in Soft PIN authentication. ServiceNow docs: Configure Soft PIN ↗
`glide.authenticate.mutual.enabled` true \| false	`true`	Not stated	-	This property activates mutual authentication, requiring both parties to present valid certificates for secure access. ServiceNow docs: ATF Health Check checks and configuration ↗
`glide.ui.max_session_timeout`	Not stated	Not stated	-	It limits the maximum effective session timeout value to 1440 minutes, influencing how long a user can remain idle before being logged out. ServiceNow docs: Minimize session activity timeout duration ↗
`glide.authenticate.session_access.user_info_message` string	`<span class='sn-sticky-notification'>Based on security policies defined by the administrator, some of your privileges have been removed from this session.<br/>Please get in touch with your administrator for more information.</span>`	Not stated	-	It specifies the notification message shown to users when some of their session privileges have been removed due to security policies. ServiceNow docs: System properties ↗
`glide.embedded.session.trust.verification.enabled`	`true`	`true`	Medium 5.3	This property enforces JWT verification for guest embedded sessions, preventing unauthorized access from untrusted sources. ServiceNow docs: Require JWT trust verification for guest embedded sessions ↗
`glide.oauth.cors.allowed.origin` string	`empty string`	Not stated	Low 3.5	This property defines which domains are permitted to make cross-origin requests to ServiceNow's OAuth endpoints, facilitating integration with browser-based applications. ServiceNow docs: Allow CORS origins for OAuth endpoints ↗
`glide.uxf.cors.allowed_assets`	Not stated	Not stated	-	This property configures Cross-Origin Resource Sharing (CORS) rules, allowing specified external domains to access the chat widget without security restrictions. ServiceNow docs: Configure the portable chat widget ↗
`com.snc.platform.security.oauth.mcp.aig_scope_support`	`false`	`true`	Medium 4.3	This property controls the caching behavior of OAuth access tokens based on requested and configured scopes, impacting how tokens are reused for different requests. ServiceNow docs: Enforce least privilege on scoped MCP OAuth tokens ↗
`sn_app_lens_core.lens_enable_auto_login`	Not stated	Not stated	-	This property determines whether ServiceNow AI Lens will automatically log in users without prompting for credentials after the initial sign-in. ServiceNow docs: Set up auto-login for ServiceNow AI Lens ↗

Outbound TLS, certificates and code signing (8)

Outbound HTTP calls (for example Integration Hub or outbound web services) can now check certificate revocation lists, and outbound certificate policies let you set TLS validation rules per host. The docs note that outbound certificate policies are opt-in and inactive by default. On the code signing side, Brazil documents strict signature validation for Flow Designer artifacts, signatures on source control commits and which tables are excluded from code signing audit.

Before enforcing CRL checks, make sure the instance can reach the CRL endpoints of the certificate authorities your integrations use.
Test outbound integrations after changing any of these settings.
MID Server IPKI registration keys: the docs recommend 3 to 5 allowed retries.

Property	Default	Recommended	Risk	What it does
`com.glide.communications.httpclient.disable_crl_check`	`false`	`false`	High 7.5	This property determines if CRL-based revocation checking is enabled for outbound TLS HTTP requests, defaulting to false, which allows for CRL checks. ServiceNow docs: Enable CRL-based certificate revocation checking for outbound HTTP requests ↗
`com.glide.communications.httpclient.fail_on_non_pass_crl_status`	`true`	`true`	Low 2.3	This property controls the termination of outbound HTTP requests based on the results of Certificate Revocation List checks, enhancing security during TLS connections. ServiceNow docs: Enforce CRL certificate revocation checking for outbound HTTP requests ↗
`com.glide.communications.httpclient.outbound_cert_policy.enabled`	Not stated	Not stated	-	This property activates the enforcement of outbound certificate policies, allowing specific SSL/TLS validation rules for defined domains. ServiceNow docs: Outbound certificate policies ↗
`com.glide.hub.code_signing.full.validation.enabled` true \| false	`false`	`true`	Medium 4.4	This property controls the enforcement of strict signature validation for Flow Designer artifacts, ensuring that only verified flows are executed. ServiceNow docs: Enforce signature verification for Flow Designer artifacts ↗
`com.glide.codesigning.tables.excluded_from_audit`	Not stated	Not stated	Medium 5.1	This property lists tables that do not generate audit entries for create, update, or delete operations, helping to maintain focus on significant changes in protected code artifacts. ServiceNow docs: Restrict vault code signing audit exclusion to defaults ↗
`sn_cse.com.snc.csf.generate_signature_commit`	Not stated	Not stated	-	This property activates the automatic generation of signatures for records during source control commits, ensuring secure tracking of changes. ServiceNow docs: Signature generation during source control commit ↗
`sn_mid_infra.registration_key.max_use_count` integer	Not stated	`3-5`	Medium 5.4	This property limits the number of allowed uses for a registration key, enhancing security by preventing excessive failed registration attempts. ServiceNow docs: Restrict MID IPKI registration key retry attempts ↗
`com.glide.aws.auth.calculate.region.and.service`	Not stated	Not stated	-	This property determines whether to calculate the AWS region and service required for authentication, impacting the success of API requests. ServiceNow docs: Configure an Amazon Signature based Custom Algorithm ↗

AI agents, voice and chat (3)

Three settings for conversational AI: step-up authentication for AI voice agents before sensitive requests, generic instead of detailed validation errors for end users, and HTML sanitization of inbound Virtual Agent chat messages before they reach agents.

If you run Virtual Agent or AI voice agents for external users, review all three.
Test a conversation flow end to end after enabling sanitization.

Property	Default	Recommended	Risk	What it does
`glide.conv_ai_voice.step_up.enabled`	Not stated	Not stated	-	This property determines whether step-up authentication is required for AI voice agents, adding an extra layer of security for sensitive requests. ServiceNow docs: Step-up authentication ↗
`glide.cs.enable_validation_error_messages` true \| false	`false`	`false`	Medium 4.3	This property controls whether detailed validation error messages are shown to end users, enhancing user experience by providing actionable feedback. ServiceNow docs: Restrict exposure of validation error details to end users ↗
`glide.cs.sanitize_inbound_messages.enabled` string	`false`	`true`	Low 3.5	This property activates a dedicated HTML sanitization check for inbound chat messages, ensuring that unsafe content is removed before reaching agents. ServiceNow docs: Enable sanitization of inbound virtual agent chat messages ↗

Data access, domains and exports (8)

Settings that decide who sees which data: export of Platform Analytics dashboards, domain access enforcement and data separation, admin access across partitions, field-level write checks on Collaborative Work Management boards, Restricted Caller Access invalidation and log forwarding in the Log Export Service.

Platform Analytics export is open to everyone by default. Restrict it with the allowed roles property if dashboards contain sensitive data.
On domain-separated instances, check which tables the domain access handler covers.

Property	Default	Recommended	Risk	What it does
`glide.par.export.enabled` true \| false	`true`	Not stated	-	This property determines whether users can export dashboards and visualizations, with the default setting allowing exports for all users. ServiceNow docs: Restrict platform analytics export to authorized roles ↗
`glide.par.export.allowed_roles` string	`Empty (no role restriction)`	Not stated	-	This property restricts the export of Platform Analytics dashboards and visualizations to users holding specific roles, provided that the export feature is enabled. ServiceNow docs: Restrict platform analytics export to authorized roles ↗
`glide.sys.domain.access_handler.included_tables`	`*`	`*`	Medium 5.6	This property specifies the tables subject to domain access handler enforcement, impacting record visibility and access evaluation for domain-separated data. ServiceNow docs: Enforce domain access control on all tables ↗
`glide.one_extend.mosaic.sync.disable_data_separation_enforcement`	`false`	`false`	Medium 5.4	This property controls the enforcement of domain-visibility filtering for data-separated instances, impacting user access to records based on their domain permissions. ServiceNow docs: Prevent disabling of data separation enforcement ↗
`sn_spm_ewd.allow_admin_access_to_all_partitions`	Not stated	Not stated	-	This property controls whether administrators can access all partitioned data across the deployment or are restricted to their assigned partitions. ServiceNow docs: Configure administrator access to all partitions ↗
`sn_cwm.enable_granular_security`	Not stated	Not stated	-	This property determines whether per-row field write access is evaluated for each work item on a CWM Board, affecting how edits are saved based on user permissions. ServiceNow docs: Properties installed ↗
`glide.sys.fencing.restricted_caller_access.invalidation_mode` string	`DB_LISTENER`	Not stated	-	Chooses whether a database listener invalidates Restricted Caller Access records when an update set commits source code changes, or whether the script engine leaves associated records intact. ServiceNow docs: Available system properties ↗
`glide.les.disable_logs_forwarding`	Not stated	Not stated	-	This property disables log forwarding in the Log Export Service when set to true, ensuring no logs are sent during critical database operations. ServiceNow docs: Update system property ↗

Security Operations and GRC (4)

Application settings in Threat Intelligence, Vulnerability Response and Policy and Compliance: extracting observables from indicators, the Wiz container integrations and how compliance scores are calculated.

Only relevant if these applications are installed. Compare compliance scores before and after changing the calculation settings.

Property	Default	Recommended	Risk	What it does
`sn_sec_tisc.extract_observables_from_indicator`	Not stated	Not stated	-	This property controls whether observables are automatically extracted from newly created indicator records, facilitating better threat analysis and response. ServiceNow docs: Set Threat Intelligence Security Center properties ↗
`sn_vul_wiz.deployment_context_gate_writes`	Not stated	Not stated	-	This property deactivates the Wiz Container Grouped Vulnerability and Wiz Container Deployment Context integrations, allowing for container vulnerable item creation based on existing settings. ServiceNow docs: Runtime exposure visibility for container images ↗
`sn_compliance.cal_score_by_weighted_control` true \| false	`true`	Not stated	-	It configures the calculation method for compliance scores by allowing weighted averages instead of flat averages, influencing the accuracy of compliance assessments. ServiceNow docs: Configure ↗
`sn_compliance.enable_association_of_citations_to_controls` true \| false	`false`	Not stated	-	Enabling this property allows citations to derive their compliance scores from linked controls rather than control objectives, affecting compliance evaluations. ServiceNow docs: Configure ↗

Check your instance

Paste this read-only background script into System Definition > Scripts - Background on a sub-production instance. It prints the current value of every property on this page. A property without a record runs on its platform default. You can also open sys_properties.list and filter by name.

// Read only: prints the current value of every property on this page.
// Run in System Definition > Scripts - Background.
var names = [
  'glide.discovery.certs.enable_incident_creation_for_expired_certificates',
  'work.management.travel.time.threshold.minutes',
  'password_reset.wf.timeout',
  'glide.ui.mentions.default_limit',
  'glide.authenticate.basic_auth.restriction.active',
  'glide.authenticate.basic_auth.restriction.enforce',
  'glide.authenticate.basic_auth.restriction.default_decision',
  'glide.authenticate.basic_auth.allowed_roles',
  'glide.authenticate.basic_auth.allowed_users',
  'glide.authenticate.basic_auth.allow_snc_external',
  'com.glide.script.sandbox.ks.watchdog.enabled',
  'com.glide.script.sandbox.ks.watchdog.phase',
  'com.glide.script.sandbox.ks.watchdog.auto.advance',
  'com.glide.script.sandbox.ks.watchdog.phase.duration.days',
  'com.glide.script.kittyscript.validation.mode',
  'com.glide.script.static_analysis.disabled',
  'com.glide.script.static_analysis.enable_sync',
  'com.glide.script.static_analysis.only_check_unauthenticated_users',
  'glide.security.scripting_governance.enabled',
  'glide.security.scripting_role.auto_provisioning',
  'glide.security.scripting_role.provisioning_job_running',
  'glide.script.dot_walk.enforce_cross_scope_access_all_tables',
  'glide.script.dot_walk.log_and_allow_violations',
  'glide.script.dot_walk.log_stack_trace_when_blocked',
  'glide.security.acl_with_invalid_roles_strict_deny',
  'glide.security.allow_unauth_roleless_acl',
  'glide.security.csrf.processor.all.authenticated.enabled',
  'glide.security.csrf.httpauth_processor_allowlist',
  'glide.security.csrf.rest.public_csrf.enabled',
  'glide.rest.policy.normalize_apply_all_fields',
  'glide.authenticate.policy_based_login_experience.enabled',
  'glide.auth_factors.softpin.enrollment.enabled',
  'glide.authenticate.mutual.enabled',
  'glide.ui.max_session_timeout',
  'glide.authenticate.session_access.user_info_message',
  'glide.embedded.session.trust.verification.enabled',
  'glide.oauth.cors.allowed.origin',
  'glide.uxf.cors.allowed_assets',
  'com.snc.platform.security.oauth.mcp.aig_scope_support',
  'sn_app_lens_core.lens_enable_auto_login',
  'com.glide.communications.httpclient.disable_crl_check',
  'com.glide.communications.httpclient.fail_on_non_pass_crl_status',
  'com.glide.communications.httpclient.outbound_cert_policy.enabled',
  'com.glide.hub.code_signing.full.validation.enabled',
  'com.glide.codesigning.tables.excluded_from_audit',
  'sn_cse.com.snc.csf.generate_signature_commit',
  'sn_mid_infra.registration_key.max_use_count',
  'com.glide.aws.auth.calculate.region.and.service',
  'glide.conv_ai_voice.step_up.enabled',
  'glide.cs.enable_validation_error_messages',
  'glide.cs.sanitize_inbound_messages.enabled',
  'glide.par.export.enabled',
  'glide.par.export.allowed_roles',
  'glide.sys.domain.access_handler.included_tables',
  'glide.one_extend.mosaic.sync.disable_data_separation_enforcement',
  'sn_spm_ewd.allow_admin_access_to_all_partitions',
  'sn_cwm.enable_granular_security',
  'glide.sys.fencing.restricted_caller_access.invalidation_mode',
  'glide.les.disable_logs_forwarding',
  'sn_sec_tisc.extract_observables_from_indicator',
  'sn_vul_wiz.deployment_context_gate_writes',
  'sn_compliance.cal_score_by_weighted_control',
  'sn_compliance.enable_association_of_citations_to_controls'
];
var found = {};
var gr = new GlideRecord('sys_properties');
gr.addQuery('name', 'IN', names.join(','));
gr.query();
while (gr.next()) {
  found[gr.getValue('name')] = gr.getValue('value');
}
for (var i = 0; i < names.length; i++) {
  var n = names[i];
  gs.print(n + ' = ' + (found.hasOwnProperty(n) ? found[n] : '(no record on this instance, platform default applies)'));
}

FAQ

What changed for system properties in the ServiceNow Brazil release?

Compared with Australia, the Brazil documentation mentions 214 system properties for the first time, 59 of them about security, and changes the documented default of a few existing ones. The largest new topics are the basic authentication restriction, the KittyScript script sandbox, scripting governance and stricter CSRF and ACL checks.

Are these properties new in Brazil?

Not necessarily. Many existed in earlier releases and are documented for the first time in Brazil, often in the security hardening guide. They are listed here because the docs now describe a recommended value and the impact of other values, which makes them worth checking during an upgrade.

Does upgrading to Brazil change my property values?

Usually not for properties that already exist on your instance. Upgrades tend to keep existing sys_properties records, so a changed default mostly affects new instances, new plugins or properties that did not exist yet. Check the actual values on your instance with the script on this page.

How do I check these properties on my instance?

Open sys_properties.list and filter by name, or run the read-only background script on this page. It prints the current value of every property listed here, or says that the property is not on the instance.

Which Brazil security properties should I look at first?

Start with the settings where ServiceNow recommends a value other than the default, listed in the overview at the top of the security section. The basic authentication restriction affects integrations directly, so plan it before the upgrade.

Something wrong or missing on this page? Tell me and I will fix it.

Send feedback