Basic recommendations

<< Click to Display Table of Contents >>

Navigation:  Automation Server > Automation Server configuration and administration guide > Initial project configuration > Best practices in the production environment > Security hardening at the IIS >

Basic recommendations


This section presents security recommendations to apply in Bizagi Work portal related to Bizagi's configuration (application hardening).

You should be authorized to work with security of access and configuration of your premises and equipment, appliances or components involved in the complete solution which are not integral parts of Bizagi, such as: the network and storage, firewalls, load balancers or other appliances, and other servers such as domain controllers or database servers.


For more information regarding the scope of these recommendations, refer to Security setup recommendations.



The following recommendations apply when Bizagi is running on a .NET platform, independently from the Web server IIS version on which it runs.

In this section, the recommended configuration presumes an IIS Web server version 7.5, and hardening is carried out according to IIS capabilities.


Before you start

Keep in mind the following considerations:


Considerations regarding the platform

Always review and apply recommendations issued by Microsoft, the vendor of the base platform on which Bizagi runs for .NET environments.

Consider bulletins and notifications about fixes and patches announced by Microsoft regarding your Windows OS or the IIS.

Remember to carry out proper tests after applying fixes and patches to verify you are not affecting your Bizagi project.


Considerations regarding the database

For a higher level of security regarding data access, Bizagi lets you configure the service account which is used to configure database access through the Work portal and the Scheduler service to have the minimum required rights.

For more information about the setup of these accounts, for instance when using SQL Server, refer to SQL Server prerequisites.


Considerations regarding authentication in Bizagi

Before you continue with the web-related configuration recommendations for the Work portal, make sure you establish security policies for passwords (password formation and length, duration, and other elements for protection and compliance with network security requirements).

When using local authentication for Bizagi, configure the relevant parameters to cover such policies, as described at Bizagi authentication.


We recommend that you set up as a minimum the following parameters:

Enable account lockout for failed login attempts: On

Enforce Password change after first login: On

Enforce Password History: On

Enable authentication logging: On

Maximum number of failed login Attempts: 3

Password minimum age: 30 days, or according to your criteria.

Minimum length of passwords: 8 characters, or according to your criteria.

Enforce the use of letters in passwords: On

Enforce the use of capital letters in passwords: On

Enforce the use of lower-case in passwords: On

Enforce the use of numbers in passwords: On

Enforce the use of special characters in passwords: On

Idle session time-out: 5 minutes.

Enforce validation of sequences in passwords: On

Account lockout duration: According to your criteria.


Considerations regarding the system user in Bizagi

Recall that domain\admon is the system user created by default and employed internally by Bizagi.

Neither Username nor password should be changed for this user.

You may not disable this user since it is needed to perform automatic tasks related to processes such as timers and scheduled jobs. We recommend you to make sure that this user is always enabled in your project.

We strongly recommend that you edit this user's settings so that it that it does not have access to administration options in the Work portal (it should be able to start specific processes and run tasks, but not a full admin). Refer to Security for Work Portal menus.

To make sure this exclude this user from those authorized to manage your Bizagi system (This user should not be able to manage users, nor modify values in Bizagi such as parameter entities, cancel or delete cases, etc).


Basic recommendations

Follow the configuration recommendations to mitigate most vulnerabilities.

These apply to your testing and pre-production environments as well (when using one).



For the next steps, make sure you have installed the IIS component World Wide Services -> Security -> Basic Authentication, and IP and Domain restrictions (when installing IIS). Review the IIS instalation.


Using the HTTPS protocol

We strongly recommend that you configure your Bizagi Work Portal using the HTTPS over TLS protocol.

To do this, make sure you have a valid certificate for your server which registers to your server's domain.


Once you have a valid certificate for your server, register it for the Bizagi Work portal by using the Server certificates option for the IIS Server:




Once the server is registered, specify the bindings in the Work portal's web site (by default, at Default Web site):




For the bindings, you will be able to specify HTTPS use, with its secure port, and select the appropriate registered certificate.

Click OK to save this configuration.



When using HTTPS, consider editing the web.config file to specify <add key="PROTOCOL" value="HTTPS"/>.

This applies when using case links in process notifications, as described at Notifications using case links.


Enabling a secure TLS version

The Bizagi Work Portal supports the following protocols:


TLS 1.2



We strongly suggest to use the TLS 1.2 secure protocol and deactivate the others.


To activate the TLS 1.2 protocol in your IIS server you must follow these steps:


1. Backup your registry files

Open the Registry Editor typing Regedit in the search option of your windows. From the File tab, select Export, and save the reg file from all branches.


2.  Add the TLS 1.2 key

In the Registry editor, navigate to this location:




Include the TLS 1.2 key under Protocols folder. This look like a new directory under the Protocol folder.


3. Create two keys in the TLS folder.

Right click the TLS 1.2 folder and create the Client and Sever key.


4. Create values

Right click the right panel and create the DWORD values under both Server and Client keys as follow:


DisabledByDefault [Value = 0]
Enabled         [Value = 1]




5. Disable TLS and SSL older versions

under the same location:



locate the DWORD values of TLS 1.0 , 1.1 and SSL 3.0 and set the Enabled value to 0.


Forcing the TLS version

If you are using HTTPS with the TLS protocol and you have to use a specific version (e.g., version 1.1 or 1.2), you must add the following key in the <appsettings> section of the Work Portal's web.config file (usually located in C:\Bizagi\Projects\[Project_Name]\WebApplication):


<add key="TLSSupport" value="Tls1.2" />



Bear in mind that the key value is case sensitive. Thus, you must add it as specified above to set the TLS protocol version (in this case, version 1.2) correctly.


Consider reviewing if the end-user browser has the TLS enabled. These browsers versions enable the TLS 1.1 version by default:



Version where TLS 1.1 is enabled by default

Internet Explorer


Microsoft Edge

All versions

Google Chrome





To review if TLS is enabled in your browser, follow these steps:


Microsoft Internet Explorer

1.Open Internet Explorer

2.From the menu bar, click Tools >  Internet Options > Advanced tab

3.Scroll down to Security category, manually check the option box for Use TLS 1.1 OR Use TLS 1.2.


Google Chrome

1.Connections are automatically negotiated at the highest grade.

2. If you are using Google Chrome version 22 or greater, TLS 1.1 is automatically supported. TLS 1.1 & 1.2 are automatically enabled from version 29 onwards.


Mozilla Firefox

1.Open Firefox

2.In the address bar, type about:config and press Enter

3.In the Search field, enter tls. Find and double-click the entry for security.tls.version.max

4.Set the integer value to 4 to force a maximum protocol of TLS 1.3.


Configuring a secure SSL/TLS Cipher suite

The SSL/TLS is a protocol that defines the usage cryptography algorithms to guarantee integrity, confidentiality and authentication for the OSI/TCP transport layer. These algorithms are often referred as SSL/TLS Cipher Suite.  To prevent systems from crypto hacking techniques, it is necessary to maintain a secure and updated Cipher Suite. By restricting the SSL/TLS Cipher Suite you could improve the security of SSL/TLS communications.


To do this, open the Run command and type gpedit.msc to open the  Local Group Policy Editor.




Go to Computer Configuration > Administrative Templates > Network > SSL Configuration Settings.




Double click on SSL Cipher Suite Order and select the enabled option.




Set the SSL cipher suite ordered from the most secure to the least secure sorted by comas. Click ok to finish the configuration.




When the SSL/TLS communication starts, the server will offer the encryption algorithms specified in the Cipher Suite. Then the client and the server will choose the algorithm that both support within the list starting from the first one to the last one.



We suggest to use the following list of SSL Cipher Suites:



Filtering unauthorized requests

We recommend you to identify the gateway from which your end users access the Bizagi Work portal.

This way, you can use a range of valid IP addresses to filter HTTP requests to your application.


To do this, include a white list of IP addresses authorized to access the Bizagi Work portal at the site level (you may even specify an authorized domain).

Use the IP Address and Domain restrictions option:





Similarly, you may rely on Web Application Firewall products to harden security to access Bizagi (to rely on additional features such as those oriented to intrusion detection, etc, and to consider corporate policies to secure your application especially when having Bizagi setup for internet access).


When using a DMZ, make sure that both the inside and outside firewalls do not allow indiscriminate access through firewall configuration and ports.



For Bizagi, security is an aspect of critical importance.

Therefore, Bizagi periodically releases new versions which feature improvements and fixes for issues detected in previous versions.

Fixes for those detected issues may include specific solutions for identified security vulnerabilities.


We strongly recommend you to consider a periodic upgrade to Bizagi's latest releases for your solution, by always following the usual guidelines for an upgrade procedure, including:

Plan, coordinate and appropriately test these upgrades.

Rely on an array of environments (development, testing, pre-production when applicable, and production).

Take proper contingency measures (e.g backups) before upgrading.

Evaluate customizations or additional security configurations such as the ones listed above, so that stakeholders are aware that it is part of the plan to reconfigure certain components after the upgrade.



When having customizations or applying hardening measures such as the ones above, follow one of these two alternatives  when carrying out a version upgrade:


1. If doing the upgrade through Bizagi Management Console, you will need to reconfigure and verify that such measures are still applied after the upgrade. We recommend backing up customizations before starting the upgrade.

By default, an upgrade carried out through the Management Console will not check whether you have done modifications to the original files and file structure.


2. You may choose to do the upgrade through a manual procedure (without using the Bizagi Management Console).

If you do, consider all the relevant components and files that you need to replace manually for the Work Portal and Scheduler, while avoiding overwriting your configured customizations or the already applied hardening measures.


For highly critical security issues, Bizagi may consider issuing hot fixes and recommend that you apply them without awaiting for a newer version.


To evaluate or consider additional application hardening aspects, refer to Intermediate recommendations.