Skip to main content
Verify the version tags to ensure you are consuming the intended content or, complete the latest version.

Security policies

The time to consider application security is early on, such as during the Prepare phase of your project, before you begin to build and configure the application. To protect your application from hackers and prevent unauthorized access and use, you need to manage two types of security: application-level and feature security.

Application-level security

Application-level security focuses on protecting the application from outsiders and unauthorized users. For example, with application-level security you:

  • Reduce the risk of unauthorized users getting into or stealing data from your application
  • Identify authorized users who need access to the application
  • Create password and authentication policies

Application-level security considers all the ways you can protect the application, such as using third-party security tools or setting up multi-factor authentication. The goal of application-level security is to make it impossible for non-authorized users to break into, read, or otherwise access your application.

Feature security

Feature security focuses on the application by determining the case types, features, and data that authorized users can or cannot access. For example, with feature security you:

  • Set up security roles for personas identified in each case type so that authorized users can access the application features they need
  • Prevent users from viewing features or accessing data to which they should not have access
  • Design role-based access control (RBAC), attribute-based access control (ABAC), and client-based access control (CBAC)
Note: To review setting up users and personas, see Inviting users to an application

For example, in a Payroll application, the business owner wants each manager to be able to view the pay history of their direct report employees, but not view the pay history of peers or other staff members. In addition, no manager can manually change the pay rate of the employee. However, the payroll manager and the CFO can view pay history for all employees as well as update pay rates. As you document the manager user story, consider what payroll features the manager can and cannot access.

Note: As a best practice, SSA and LSA team members should identify security needs during the Discover (Sales) phase of a project and document them during the Design phase. To ensure security is set up correctly, it is a best practice to add security requirements to the definition of done (DoD) for each feature and test requirements to meet the DoD during the Build phase. For more detail on phases within Pega Express, see Pega Express Delivery

Check your knowledge with the following interaction:

Application security configuration on Pega Platform

One way to limit unauthorized access to your applications is to configure the settings on the Security Policies tab of the Authentication landing page in App Studio. In Dev Studio, open the Configure menu and select Org & Security > Authentication > Security Policies to view and update the security policies for the entire Pega Platform™ server.

Caution: Settings for a specific authentication service may override settings on the Authentication landing page.

After you update a setting, click Submit at the bottom of the page to record an update. Changes to security policies become active immediately on form submission.

Note: Applying appropriate security policies is only one aspect of securing an application. For a complete list of security leading practices, see the Security Checklist concept for Pega Platform deployment. 

The Security Policies tab is separated into a Frequently required policies section and Other policies section. Password, CAPTCHA, Lockout, and Audit are Frequently required policies, and Multi-factor authentication and Operator disablement are Other policies.

Policy name Description Policy configuration options
Password Governs the strength of user passwords. Use the Password policies section to customize requirements for password length, complexity, and predictability.
CAPTCHA Tests whether a person entered the password.


Use the CAPTCHA policies section to configure a CAPTCHA to challenge login attempts. When enabled, you can:
  • Choose between the default implementation or a custom implementation.
  • Enable the use of a CAPTCHA on the initial login.
  • Set the likelihood that users receive a CAPTCHA after a failed login.
Lockout Defines system behavior when users enter an incorrect password.


Use the Lockout policies section to customize when and how long users must wait after a failed login attempt. The options listed depend on whether the lockout policy is enabled or disabled. When a lockout penalty is enabled, you can:
  • Set a threshold value for failed login attempts.
  • Set the initial lockout penalty period in seconds. Repeated login failures increase the penalty period automatically.
  • Maintain a log of login failures for a specified number of minutes.

When a lockout policy is disabled, you can:

  • Set the number of allowed failed login attempts before an account is locked.
  • Set the time in minutes for when the user's account is locked.
Audit Determines the amount of detail written to the system log for a security issue. Use the Audit policies section to customize the level of detail captured for login attempts.
Multi-factor authentication Defines multiple factors, or pieces of evidence, that users must provide to verify their identity. Use the Multi-factor authentication policies (using one-time password) section to configure the settings for a one-time password that is provided to users by email or SMS text message. To complete the login process, users must enter the one-time password within the allowed time. 
Operator disablement Defines the duration of inactivity before disabling access for a user. Use the Operator disablement policy section to automatically disable access for users who are inactive for the specified number of days. To prevent the system from disabling access for users who need access, add the operator ID record for the user to the Exclusion list of operator IDs list.
Note: For a detailed explanation of the settings for each type of policy, including minimum and maximum allowed values, see Security policies settings.

Multi-factor authentication policies

Passwords represent one way to authenticate users. To increase security, enable multi-factor authentication to authenticate users. With multi-factor authentication, users gain access only after providing multiple factors, or pieces of evidence, to verify their identity.

Note: Two-factor authentication is a subset of multi-factor authentication, in which users provide two pieces of evidence at login.

In the following image, click the + icons to learn more about the different multi-factor authentication factors:

Check your knowledge with the following interaction:

This Topic is available in the following Module:

If you are having problems with your training, please review the Pega Academy Support FAQs.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice