My first look at User Security Governance

,
User Security Governance

In the autumn of last year, Microsoft shared a blog focusing on managing user security, visibility, and compliance for Microsoft Dynamics 365 F&O. Shortly thereafter, a post from Executive Automats revealed that Microsoft had plans to include features initially developed as ISV into the standard solution. The features are recently announced in the new 2025 release wave 1 plan. The feature called User Security Governance is currently in preview available in version 10.0.43. In this post, I will share my first experiences.

In this post

My interest
Feature management
Parameters and setup
Security roles process maintain
Security analysis
License usage summary
Temporary role management
Roles violating segregation of duties rules
Privileged user management
Conclusion

My interest

Security is one of my main areas of interest. Security is not easy. Understanding the full architecture is important for several reasons. Without proper understanding, you might run into several challenges, like:

  • Not able to get security implemented as required
  • Over permissioned security roles and users
  • Too high license requirements compared to what users actually need.

The complexity of security is underestimated. Everyone can easily talk about security roles, duties, privileges, and menu items. Security is more than just granting access to menu items. It is not only about menu items. For example, you need to take care of data entities, form controls, and table permissions. I wrote about this before. You can find these blogs and more here: Security topics. The contents of the roles also determine the license SKUs required for the user.

In the security administration areas, there has been a lack of easy tooling for creating security roles, getting insights into what permissions a user has, and checking license compliance. Several ISVs do offer enhanced features for clients. I worked at To-Increase (rebranded to Staedean) before where I also contributed to their Security and Compliance Studio. Fastpath offers a solution hosted outside of Dynamics 365 where you can manage security and gain insights across different applications.

Microsoft now admitted that focus on user security governance is an important topic and they acquired a solution from Executive Automats. There might be some other solution in the market as well offered as ISV or a partner solution.

Feature management

Recently, the preview of Microsoft Dynamics 365 Finance version 10.0.43 became available and of course, I installed the solution and started to click around. Initially, the new features are not visible. For that purpose, you will need to enable the User Security Governance feature in Feature Management.

When you enable the feature, reload the browser to create a new session where the new menu items are visible.

Now let’s explore some features. Before I jump into the details an important note. The user security governance features are in preview. During my exploration of the module, I encountered several issues and errors. These are or will be reported to Microsoft to ensure the product is stable once it becomes generally available. One issue is already under investigation where an unexpected error is raised when the feature is enabled in feature management and you want to assign users to security roles. Despite the error, the role is assigned as intended.
In addition, I still need to learn all the specific details and will write about more details in future blog posts. So, the below details are from my first impressions and are not a comprehensive user guide.

Parameters and setup

My first thought was to use the new feature to create a role, but then I realized that usually there is a need for some general setup. You can find security governance-related parameters using the next path: System administration > Setup > Security governance setup > Parameters (preview).

On the tab Basic license cost, you can enter the monthly fee per SKU in your own preferred currency. When completing the lines, there is a confusion about the difference between the user licenses with and without the word Basic. After reviewing some other forms, the Basic Finance is the base SKU and the licenses without a prefix, such as Finance is the attach license. In the list with options, I do miss at the moment enumerations for the premium licenses (Finance and SCM). Also, there is no option to specify the price of Device licenses. This information is used on other forms which I will discuss later in this blog.

On the tab User aging reports you can specify buckets in days which will be used for reporting to check users presence in the application for e.g. 30, 60, 90, 180, and 360 days.

Next to the parameters there is another page where you can define categories for processes. System administration > Security > Security governance > Security category (preview).

On this page, you can’t maintain a complete process hierarchy. I thought to use the processes as defined in the Business Process Catalog. On another page, you can maintain the process hierarchy per category. At a minimum, you will need one category set up. You can also Backup and Restore the security category from this page. I will share a small trick later for creating a shareable hierarchy between environments as I lost a lot of time due to encountering errors in several environments. Then I had to recreate my hierarchy three times.

Security roles process maintain

Let’s dive into the helpful features added as part of the User Security Governance module. One of the major forms is a page where you can maintain a security process hierarchy and roles with their contents. This is an additional way of creating security roles next to the Security configuration form or using Visual Studio. The purpose is to make role creation quicker and easier. In addition, there is support for version control which is a requirement in several businesses, such as life science.

With the earlier created Security category, you can build an hierarchy by clicking + New process. Reselect the first node if you want to add more items on the root. Each level of the hierarchy is supporting the creation of a role. I wouldn’t recommend to create roles on the end-to-end scenario level, but you can create another level for each role like the highlighted record in the screenshot below. Depending on your preferences or requirement, you can add another level first before the actual security role level.

When you have finished the initial hierarchy, you can export a backup for future restoration or another environment. When you want to build a role, you need to click Create a new role on the action bar of the Role definition section. This will initiate a placeholder for a newly configured security role.

You can use the task recorder to record all actions that should become part of the new security role. In this blog, I will not elaborate on how to create the task recordings. The task recorder will have details about opened pages and actions performed. You can load the saved task recording by using the action called Load from task recording which is “hidden” behind the (more) button as highlighted in the screenshot below.

In this walkthrough, I disabled the options Include table permissions and Include control permissions to present a small list with recorded menu items only. The disabled options will add table permissions for all tables used on the recorded forms. The same is valid for form controls. One of the earlier feedback I provided to Microsoft is a request to have an option to only add table permissions in case forms have tables and/or fields used where the table permisssions framework is enabled. This will ensure consistent security implementation where in the standard application tables and fields are part of particular privileges.

The import has some logic to determine if, during the recording only a page was opened, or more actions were performed, like adding or deleting records. It will create a list with the required entry points including the discovered access requirement. So if you need full access to particular menu items, ensure you add and delete a record during the task recording. You can still Update permissions when the list is presented on the grid. The permissions show two obsolete permission types that I reported to Microsoft. The Correct and Invoke permission types are legacy from Dynamics AX 2012 and not used in Dynamics 365. You can ignore these.

The next step can be checking for existing duties and privileges. In this demo, I will choose the fastest option to create a new duty. It will create a directly a new privilege with the same name as provided for the duty. Personally, I dislike this option, but it is a quick way to create the role content. You can then click on Save role. The details will be maintained on the Security configuration form where you can review and publish the changes.

In this demo, I didn’t follow best practices like naming conventions. Having one large recording with one duty, one privilege and a lot of entry points will not enhance visibility on analysis security contents. The idea from the security architecture is having a role consisting of one or more duties and for each duty one or more privileges that can be reused like building blocks. This easy way of role creation is quick but doesn’t follow all best practices. There is more to come about the created privilege in this blog…

Security analysis

On the Security analysis form, you can view relations between security objects and potentially start an export from a grid result to Excel. Initially, the screen can be completely empty. There is a need for using the Rebuild option to build statistical tables resulting in all different views on this form.

The user entry points tab page has very useful analysis information with a count of users and a list of associated users for security roles, duties, and all the privileges. This can help with audit questions, like which users have access to change vendor bank accounts.

This is the first point where I think it is crucial to follow best practices on naming conventions and reuse standard duties and privileges as much as possible. In case you have a different privilege per role, you will not know what privileges to check for access to vendor bank accounts as example.

The Entry points history tab page shows a log of all changes in entry points configured via the new User Security Governance features.

License usage summary

The License usage summary page shows different views on required licenses for e.g. users, roles, and privileges. Like the Security analysis form, first, the information should be compiled using the Rebuild option.

Instead of running a report, you will now have information about required licenses and a number of entry points related to a license level in a direct overview. You can then check if it would be worth removing or changing permissions to lower license requirements for your organization.

On the User licenses summary tab page, you can check required licenses per person together with a summary. Note that this is still an indication and you will need to check details as this overview is not aware of possible premium licenses. In addition the view is not aware of actually assigned licenses to users in Microsoft 365.

The User Security Governance has also a concept of Unknown license. The role I created in the example is now linked to this Unknown license type. This is because of the way I created the security role. There are some elements in the role that will usually cause a SCM license requirement. The license level is based on both the menu items and privileges used in a security role. In an internal table, there is a list of almost all privileges with a linked license SKU. As I created (on purpose for this scenario) a new duty and privilege, it doesn’t know anything about the new license SKUs. As a fallback, it uses information from the individual menu items where legacy license requirements are set on properties for a Maintain and View user license. You can read more about the way licenses are determined on the blog from Alex Meyer: Current State of D365FO User Licensing – Alex Meyer. To get the best possible recommendations on this form, it is my suggestion to use as much as possible standard duties and privileges when building the security roles.

Temporary role management

In case a user is not available for work due to e.g. vacation or maternity leave, there is an option to set up a replacement in case another user should take over duties to perform in Dynamics 365. Due to an error, at least in my environment, the feature is currently not working yet. You can set up a user that will have temporary other roles with a start- and end date/time. You can then replace the current security permissions or merge them. A periodic batch job will then assign or revoke access permissions. It keeps the history of the original assigned security roles, so the changes can be reverted to a previous state.
Note that this will only manage access permissions. Workflow delegation is to be managed via an already available feature on the user options.

Roles violating segregation of duties rules

So far in Dynamics 365 F&O, you could set up segregation of duties rules which would then check for violations at the moment when security roles are assigned to a user. In the User Security Governance additions, there is an option to check if there is a violation within distinct security roles before assigning them to users. This will ensure a smoother process for creating roles that are compliant and it will prevent mitigations when a user would be assigned to such role. You can check for possible violations when creating the security role. There is also a form where you can check all roles, including existing security roles.

Privileged user management

When you have Dynamics 365 implemented and you are already live for a smaller or longer term, sometimes you might encounter an issue that needs to be investigated or particular settings need to be adjusted based on changed business. When having the security roles set up, usually normal business users don’t have and don’t need to have excessive permissions in the application. Using the Privileged user management feature, you can temporarily grant access to the application where a login will have all permissions required to perform investigations or change particular settings. The main difference with Temporary role management is that this feature requires an approval step and all actions a user is performing will be recorded in the background. This feature is also known as fire-fighter access or break-glass procedure. So the feature is intended to provide emergency access to a user in the application.

When you open System administration > Security > Security user governance > Privileged user management (preview), the next page will open.

When you open System

As a pre-requisite, you can prepare one or two user accounts which will be disabled by default with the system administrator or other roles assigned. On this form, you can set a user that will be enabled at a specific time and will have access during a limited time period. You can then check the settings and change the status to Approved using the menu item on the action bar. Once this is done, the Process action. You can run it directly or enable background operations by setting up a periodic batch job.

In my trial environment. I prepared access for “Alfonso”. After the batch job has enabled this user, you can open Dynamics 365. The first thing the user will notice is an information bar stating that all user activity is logged using the task recorder and will be available to system administrators

The user will be disabled after the end date/time as set on the privileged user management record. You can also cancel the access and enforce running the process to disable the user and terminate the running session of the privileged user.

All actions are available for review. Audit logs and records are available. It would be possible to check all changes the user has done using the replay option of the task recorder. To be able to analyze the task recordings, you can download one or more files and open them using the Task Recorder pane.

This also gives an option to export the recording to a Word document. In case sensitive data has been accessed or changed, the task recording details store the values entered by the user. This is not visible in the Word document.

Conclusion

The User Security Governance features are a welcome addition to Dynamics 365. It enriches the application for easy security role configuration, it has some better inquiry options for compliance, and it brings an option for controlled emergency access.

Personally, I think some features still need some enhancements and I will provide Microsoft with some feedback. When looking e.g at the privileged user management feature, the Approval process can be strengthened with a four-eye principle. Currently, the approval is a status change that can be performed by a single person. It will also be helpful in case a task recorder can be directly analyzed instead of downloading it and then opening it via the Task recording pane. Anyway, having the feature and all the detailed logs is already extremely valuable.

Despite Microsoft is bringing these new features, this is not replacing the requirement to know all about the Dynamics 365 security architecture and licensing details written in the Dynamics 365 Licensing guide. As shown above, it is too easy to create a rule and lose insights in the User license overview. As mentioned above, my recommendation will be reusing as much as possible standard duties and privileges for your custom roles. I do agree that the out-of-the-box example security roles a far from perfect, but the duties and privileges do offer a good granularity for required permissions. By using these standard objects, you can benefit from license insights which makes it easier to set up and validate segregation of duties.

I will continue with a more in-depth exploration of this module and hope for speedy fixes of already known and reported issues. If you want to get started yourself, you can explore the features as they are currently in public preview. The features can’t be used in a production environment yet. According to the current plan, these features will be generally available in July 2025. You can read more about this module on Microsoft Learn: Set up a process hierarchy, roles, and privileges – Finance & Operations | Dynamics 365



I do hope you liked this post and will add value for you in your daily work as a professional. If you have related questions or feedback, don’t hesitate to use the Comment feature below.


That’s all for now. Till next time!

11 replies
  1. Dexter S Chong
    Dexter S Chong says:

    The introduction of user security governance options within the D365 standard application. I have a few questions that I am hoping some feedback can be provided:- 1. In the assignment of the entry-based points to the role for the process hierarchy how accurate is the task recorded in accurately identifying all the steps for the role?, 2. Would customized roles/duties/privileges impact the accurate reporting for licenses usage and categorization, 3. Would the front-end security configuration option still be used for user security role development – [customized user security roles based on job function definition]? Or can be used in tandem with the process hierarchy set up. What is the preferred recommendation?

    Reply
    • André Arnaud de Calavon
      André Arnaud de Calavon says:

      Hi Dexter,

      Thanks for reading the blog and your questions. Note that all is also new to me and I don’t have all the answers myself today.
      1) This is something I haven’t explored in too much detail yet. At least it is recording the menu items opened during the recording and it knows if records were updated, created, or deleted to set permissions. I would like to perform some more tests myself by accessing specific form controls and using the Open in Excel feature to check for other types of permissions next to menu items.

      2) Depending on how you customize security objects, it will have an impact on the suggested license. As shown in my example, a license ‘Unknown’ was suggested as I didn’t reuse standard duties or privileges.

      3) Today, you can use either option. Microsoft did not implement restrictions. What to use depends on preferences. Future changes to the security framework are not yet planned.

      Reply
  2. Fade Olorunlambe
    Fade Olorunlambe says:

    Thank you for the heads-up on this upcoming feature. It’s really a good news to me as I wanted my organisation to allow me use the Executive automat solution for security role creation but was not approved.
    Now being part of standard feature is a welcome development.

    Reply
  3. Mukesh Kumar
    Mukesh Kumar says:

    Hi Andre, great stuff as always!

    Am working to restrict HR related confidential data from SysAdmins and other key users. Do you see any solution for that in this new release?
    At this client we have couple of SysAdmins which I know is not a good design but was done by previous partner so I am kind of restructuring the security for them. I don’t see much of challenge in restructuring the security as the client don’t have too many users + simple business process. The most difficult is to restrict access to HR confidential data in Dynamics and all linked applications like BI, Synapse, other integraions. I couldn’t think of any other solution except removing SysAdmins from all users, assign them all required roles to perform their duties except roles giving access to confidential data, will create segregation of duties, restricting table access in Synapse etc..

    Not sure if there is any other simple and faster solution to manage it. Any inputs/suggestions are most welcome.

    Regards
    Mukesh

    Reply
    • André Arnaud de Calavon
      André Arnaud de Calavon says:

      Hi Mukesh,

      The new module is not able to restrict access from the system administrators. This is due to how Dynamics 365 F&O is treating users with the system administrator role. For these users, they will bypass all security. In case you want to restrict HR related data, you will need to remove the system administrator role and use another role or combination of roles granting access to what they actually need. For reporting, you would also need to restrict access to e.g. specific reports.

      Reply
  4. Mukesh Kumar
    Mukesh Kumar says:

    Thanks Andre for your quick response. Yeah, I know SysAdmin bypasses all security, thought may be the new feature changed something, thanks for confirming. I think MS should do something to restrict HR confidential data like salaries etc. specially from SysAdmins and considering they can acess it from couple of places even if blocked in FO like BI, table browser, power platform etc. What do you think?

    Reply
    • André Arnaud de Calavon
      André Arnaud de Calavon says:

      Hi Mukesh,

      I think the system administrator role is a legacy. I try to avoid assigning this role to users. Unfortunately, there are some forms depending on this role, but I would rather see Microsoft investing in the option to have all features covered correctly by using other security roles. Or like you mentioned have the option to restrict access to sensitive data.

      Reply
  5. Marijan Sivric
    Marijan Sivric says:

    Great post as always…and some cool features! But I think there is much more that could be done from Microsoft’s side to improve the process of maintaining user access in D365. One example is not having the legal entity code when assigning legal entities to specific user roles. Another is related to assigning multiple legal entities to multiple security roles in one go. This is some basic stuff, and I hope Microsoft will add these features in the future.

    Reply
    • André Arnaud de Calavon
      André Arnaud de Calavon says:

      Hi Marijan,

      Thanks for your thoughts. You are referring to the fact that with organization assignments you can only see the company name and not the ID? That is something I developed as customization several times at clients. Assigning multiple legal entities to multiple roles can be done with a workaround in case you are using automatic role assignment or the Entra ID group integration. Anyway when you use manual role assignments, I agree this is missing in the standard.

      Reply
  6. Sourav Dey
    Sourav Dey says:

    Hi,

    Just wanted to check on the reporting level used for the native Segregation of Duties (SoD) reporting in D365 F&O. I believe currently the SOD conflict reporting is at Duty level and not up to the object/privilege level. Any idea whether Microsoft has plans of changing the reporting level since reporting to only the duty level leads to false positives in SOD reporting (in case a conflict causing privilege/object is removed from duty it will still report as violation).

    Thanks in advance,
    Sourav

    Reply
    • André Arnaud de Calavon
      André Arnaud de Calavon says:

      Hi Sourav,

      I’m not able to tell you about future plans from Microsoft in this area. You can check out for ISV solutions offering enhanced features in relation to SoD. Examples: FastPath by Delinea or Security and Compliance Studio from Staedean.

      Reply

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.