Business Central Security, Roles and Permission Sets Explained

Ask most organisations to show you the security design behind their Business Central environment and you will get an uncomfortable pause. There is rarely a design document, rarely a role model on paper, and rarely anyone who can explain why a particular clerk can post to the general ledger or why a warehouse operator can also edit vendor bank details. Security in an ERP is almost never designed. It is assembled under go-live pressure, by copying whatever permission sets got the users past their errors on day one, and then it is frozen in place for years while the business changes around it. That is how you end up with a finance system where nobody actually knows who can do what, which is the opposite of what an ERP is supposed to give you. This guide is about doing it deliberately instead.

The message up front: security in Business Central is not a switch you flip, it is a model you design. Authentication proves who a user is, authorization decides what they may do, and permission sets are the building blocks in between. Get the model right, keep it small and role-based, and the system stays both safe and usable. Skip the design and you get either a lockdown that generates a permission ticket a minute, or a free-for-all where everyone is effectively an administrator. Neither is control.

1. Why ERP security is a design task, not an afterthought

An ERP is the system of record for money, inventory, contracts and master data. Every posting either is a financial transaction or feeds one. That is exactly why security here is different from securing a content site or a departmental app: the thing you are protecting is the integrity of the numbers the business runs on and reports to auditors, banks and regulators. When security is weak, the failure mode is not a defaced page, it is a fraudulent payment, a fabricated credit note, or a set of accounts nobody can defend because too many hands could touch them.

The reason security gets treated as an afterthought is understandable and worth naming honestly. During an implementation, the pressure is all on function: can the invoice post, can the order ship, can the report run. Security is friction against that pressure, because the fastest way to get a user working is to give them broad access and move on. So teams do exactly that, promising themselves they will tighten it after go-live, and then go-live is followed by stabilisation, and stabilisation by the next project, and the temporary broad access becomes permanent. I have walked into environments three and four years post go-live where the majority of users still carried a near-administrative footprint that was granted as a temporary measure in week one.

Treating security as a design task means deciding, before the model exists, what the roles in the business actually are, what each role needs to do its job, and what each role must be prevented from doing to preserve control. That is a business exercise as much as a technical one, and it cannot be delegated wholesale to the implementation partner, because the partner does not know which of your staff should be allowed to release a payment run or override a credit limit. Those are decisions about your control environment, and they belong to your finance and risk leadership. The technology then enforces the decisions; it does not make them for you. For a sense of where this sits in the wider rollout, the Business Central implementation journey pillar places security design in the sequence where it belongs, which is early, not at the end.

2. How Business Central security is structured (authentication and authorization)

The single most useful thing to understand before you touch a permission set is that Business Central security has two distinct layers that answer two distinct questions, and confusing them is the source of endless muddled thinking. The first layer is authentication, which answers "who is this user, and are they really who they claim to be." The second layer is authorization, which answers "now that we know who they are, what are they allowed to do inside the application." These are separate concerns with separate mechanisms, and a healthy design treats them separately.

Authentication in the online product is handled by Microsoft Entra ID, the identity service formerly known as Azure Active Directory. Users do not have a password stored in Business Central; they sign in with their organisational identity, and Entra ID vouches for them. This is a genuine strength, because it means all the identity controls your organisation already invests in, multi-factor authentication, conditional access, sign-in risk policies, apply to your ERP for free, without Business Central having to reinvent any of it.

Authorization is handled inside Business Central through a layered structure of entitlements and permissions. At the coarsest level, the user's licence determines the universe of what they are even permitted to touch. Within that universe, permission sets grant specific rights to specific objects, and those permission sets are assigned to users either directly or, far better, through groups. The mental model that keeps this straight:

Every layer is a narrowing. The licence sets the outer boundary and nothing inside can exceed it. Permission sets carve out specific capabilities within that boundary. Group assignment applies those capabilities to people by role rather than one user at a time. Read the stack from the top and you can always answer the two questions that matter in any audit: who is this, and what can they do. Design the stack deliberately and those answers stay clean; assemble it by accident and they become the tangle I described at the start.

3. Entra ID sign-in and identity

Because authentication is delegated to Entra ID in the online product, the front door to your ERP is only as strong as your identity posture, and this is the part of ERP security that finance teams most often assume is somebody else's problem. It is not somebody else's problem; it is the foundation the whole authorization model stands on. A perfectly designed permission structure is worthless if an attacker can sign in as a legitimate finance user because that user had no multi-factor authentication and reused a password that leaked elsewhere.

The controls that matter here live in Entra ID, not in Business Central, and the good news is that most organisations already own them. Multi-factor authentication should be non-negotiable for anyone who can touch financial data. Conditional access policies can restrict sign-in by location, device compliance or risk level, so that a session from an unmanaged device in an unexpected country is challenged or blocked before it ever reaches the application. Sign-in risk and identity protection policies can react to credentials that appear compromised. None of this is Business Central functionality, and all of it protects Business Central, which is exactly why the identity layer deserves a seat at the ERP security table rather than being left to the IT team in isolation.

There is also a lifecycle benefit that is easy to underrate. When identity is centralised in Entra ID, the joiner-mover-leaver process that HR and IT already run for email and other systems extends naturally to the ERP. A leaver disabled in Entra ID loses access to Business Central at the same moment they lose access to everything else, rather than lingering as a live ERP account because nobody remembered to deactivate them separately. That single integration closes one of the most common and most dangerous gaps in ERP security, the orphaned account, which I will return to near the end. For the broader picture of how Business Central leans on the rest of the Microsoft stack for exactly this kind of leverage, the Business Central and the Microsoft ecosystem pillar is worth reading alongside this one.

4. Permission sets: the building blocks of access

Permission sets are where authorization becomes concrete. A permission set is a named collection of permissions, and each permission grants a specific level of access to a specific object. The levels follow the familiar pattern of read, insert, modify, delete and execute: the right to view a record, to create a new one, to change an existing one, to remove one, and to run an action or report. A permission set might grant read and modify on a range of sales tables and execute on a set of related pages and codeunits, and nothing else. That precision is what makes the model powerful, and also what makes it easy to get wrong through carelessness.

Business Central ships with a large library of built-in permission sets that cover common functional areas, and these are genuinely useful as starting points because they were designed by people who understand which objects hang together to make a coherent capability. The built-in sets are, however, deliberately generous in places, because a shipped default has to work for the widest range of customers, and breadth is safer for a vendor than a default that leaves users unable to work. That generosity is fine as a reference and dangerous as a final answer. The practitioner's discipline is to treat the built-in sets as a catalogue to learn from, then compose your own assigned access from the specific capabilities each role actually needs.

There is a helpful capability for building permission sets by observation: you can record a session while a user performs the tasks of their role, and the system captures the objects and access levels that were actually exercised, which you can then turn into a permission set. Used well this is a fast way to discover the real footprint of a job rather than guessing at it. Used carelessly it captures whatever the recorded user happened to do that day, including one-off actions that should not become part of the permanent role, so the output of a recording is a draft to review, not a finished set to assign. The judgement is in the review, not the recording.

The honest limitation: permission sets can become their own kind of sprawl. Every organisation I have audited that started composing custom sets without a naming convention and an owner ended up with dozens of near-duplicate sets whose differences nobody could explain, which is just a different flavour of the same problem as no design at all. A permission set library needs a custodian, a naming standard, and a periodic cull, or it rots exactly the way the user assignments it was meant to clean up would.

5. User groups and security groups

Assigning permission sets to users one at a time does not scale and does not survive contact with reality. The moment you have more than a handful of users, direct assignment becomes an administrative burden and, worse, an audit nightmare, because the same role ends up configured slightly differently on every person who holds it. The answer is to assign permission sets to a role once and then place users into that role, so that access is defined by what job someone does rather than by a bespoke bundle attached to their individual account.

Business Central supports grouping in two related ways, and it is worth being clear about the direction Microsoft has moved. Historically, user groups were the mechanism inside Business Central for bundling permission sets and assigning them collectively. More recently, the platform aligns with security groups defined in Entra ID, so that the same group your organisation already uses to manage access elsewhere can drive Business Central permissions. This is the same philosophy as the authentication story: lean on the identity platform your organisation already governs rather than maintaining a parallel structure that drifts out of sync.

The practical payoff of security-group-driven assignment is significant. When a new finance clerk joins, they are added to the finance clerk security group as part of the standard onboarding, and they inherit exactly the ERP access that role carries, no more and no less, without anyone hand-assembling permission sets on their account. When they move to a different team, their group membership changes and their access follows. When they leave, they drop out of the group and the access evaporates. Access becomes a property of the role and the group membership, not a manual configuration that someone has to remember to build up and tear down. That is the difference between an access model that stays clean and one that decays, and it is almost entirely a matter of discipline in how you assign rather than any special feature.

The caution I always add: groups only help if the roles they represent are real and few. If you create a group per person, you have reinvented direct assignment with extra steps. If you create a hundred overlapping groups because nobody would decide on a canonical set of roles, you have moved the mess rather than solving it. The value of grouping is entirely dependent on having a small, well-defined set of roles that genuinely describe how the business works, which brings us to the parts of the design that matter most.

6. Licence types and entitlements (what a licence lets a user do)

There is a layer of the authorization stack that sits above permission sets and that many administrators forget exists until it surprises them, which is the licence and its entitlements. Your permission sets can only grant access to what the user's licence already permits. A licence in Business Central is not merely a commercial line item; it carries an entitlement that defines the outer envelope of what that seat is technically allowed to do, and no permission set, however generous, can push a user beyond the envelope their licence defines.

This matters in two directions. In the security direction, it is a genuine and free control: a user on a limited-capability seat simply cannot perform certain actions no matter what permission sets are attached, because the entitlement forbids it at a level above the permission model. That gives you a coarse but robust outer boundary that is very hard to misconfigure, because it is tied to the seat rather than to fallible manual assignment. A team member on a light seat intended for occasional read-and-approve activity cannot be accidentally turned into a full transactional user by a careless permission grant, because the entitlement will not allow it.

In the operational direction, the entitlement is a common source of confusion during troubleshooting, and it is worth knowing so you do not waste an afternoon on it. When a user cannot perform an action and you have checked their permission sets and everything looks correct, the answer is sometimes that their licence entitlement does not cover the action at all, so the permission you granted has nothing to attach to. The effective permission a user has is the intersection of what their licence entitles and what their permission sets grant. Both have to allow the action; either one can block it. Reading the two layers together is the only way to reason correctly about why a user can or cannot do something, and it is the first thing I check when a permission problem does not make sense at the permission-set level.

7. Segregation of duties and least privilege

Two principles sit underneath every good ERP security design, and if you internalise only two ideas from this entire guide, make it these. The first is least privilege: every user should have exactly the access their job requires and nothing beyond it. The second is segregation of duties: no single person should be able to control a whole sensitive process end to end, because concentration of control is where fraud and undetected error live. These are not abstractions; they are the practical shape a control environment takes, and auditors will test both.

Least privilege is easy to state and constantly eroded in practice, because it is the direct opposite of the path of least resistance. The pressure at every moment is to grant a little more access to get a user unstuck, and each individual grant seems harmless. The erosion is cumulative and invisible until an audit or an incident reveals that a mid-level clerk has quietly accumulated the ability to touch half the system. The discipline of least privilege is not in the initial grant, which everyone gets roughly right; it is in the ongoing refusal to keep adding, and in the periodic review that strips back what has crept in. A role model that is defined once and never pruned will always drift toward over-permissioning, because grants accumulate and revocations almost never happen unless someone deliberately makes them.

Segregation of duties is the sharper of the two, because it is about combinations rather than individual capabilities. The classic examples are the ones every finance professional knows: the person who creates a vendor should not also be the person who pays it, the person who raises a purchase order should not also be the person who approves it, the person who posts a journal should not also be the one who reconciles the account it hits. Each of those capabilities is legitimate on its own; the danger is in one person holding both halves of a control that is supposed to require two people. A security model that grants access capability by capability without ever checking which combinations it is creating will produce segregation-of-duties conflicts by accident, and those conflicts are precisely what an auditor hunts for.

The insight that reframes the whole exercise: designing ERP security is not primarily about deciding what each role can do. It is about deciding what each role must be prevented from doing, and which combinations of capabilities must never land on one person. Approaching the model from the prohibitions rather than the permissions is what turns a pile of access grants into an actual control environment. The permissions are the easy half; the prohibitions are where the security lives.

Approval workflows are the natural partner to segregation of duties, because they enforce the second pair of hands that segregation requires. When a payment or a purchase order must be approved by a different person before it takes effect, the workflow makes the separation operational rather than merely aspirational, and it does so in a way that leaves a record. The Business Central approval workflows pillar covers this in depth, and I would treat security design and approval design as two halves of the same control conversation rather than as separate projects.

8. Field-level, data and company-level access

Permission sets grant access at the level of objects and access types, but real control environments often need finer or broader boundaries than "can this user touch this table." Business Central gives you several complementary ways to shape access beyond the basic permission, and knowing they exist keeps you from either over-granting because the blunt tool was all you reached for, or concluding that the system cannot express a control that it actually can.

At the broadest level is company access. A single Business Central environment can hold multiple companies, and a user's access can be scoped so that they operate in some companies and not others. For a group with several legal entities, this is a primary control: the finance team of one subsidiary need not, and generally should not, be able to view or post in the ledgers of a sibling entity. Getting company-level scoping right is often more consequential than any individual permission fine-tuning, because it draws the largest boundaries around who can see and touch which set of books.

Within a company, access can be narrowed by data as well as by object. Rather than granting a user rights to an entire table, you can constrain the rows they can work with, so that, for example, a regional salesperson sees and edits only the records associated with their region. This kind of row-level scoping lets one permission model serve many users who do structurally the same job on different slices of the data, without giving each of them sight of the whole. It is more effort to set up than a flat grant, and it is exactly the effort that distinguishes a considered model from a lazy one where everyone in a function can see everything the function touches.

At the finest level, individual fields can carry their own sensitivity. Some data, personal information, bank details, salary figures, is more sensitive than the record it sits on, and the platform allows particularly sensitive fields to be classified and protected so that access to a record does not automatically mean access to its most sensitive contents. The practitioner's point across all three levels is the same: access is not a single dial from none to all. It is a set of nested boundaries, company then data then field, and a good design uses the boundary that matches the actual control requirement rather than reaching for the object-level permission for everything and hoping it is close enough.

9. Auditing access and change logging

A control that cannot be observed is not really a control, because you have no way to know whether it held. Preventive security, the permission model that stops the wrong action, needs to be paired with detective security, the logging that records what was actually done, so that you can both investigate incidents and demonstrate to an auditor that the controls operated as designed. Business Central provides the raw material for this, and the discipline is in configuring it deliberately rather than assuming it is on.

Change logging lets you record modifications to selected data, capturing who changed what and when across the tables and fields you choose to monitor. The important word is "selected," because logging everything is both a performance burden and a way to bury the signal that matters under a mountain of noise. The right approach is to identify the truly sensitive data, master data such as vendor bank details, key financial setup, credit limits and posting configuration, and log changes to those deliberately, so that when a payment goes somewhere it should not have, you can reconstruct exactly when the bank detail was altered and by whom. That reconstruction is often the single most valuable artefact in a fraud investigation, and it either exists because someone configured the log, or it does not exist at all.

Alongside change logging, the platform records administrative and security-relevant events, so that changes to permissions themselves, and to the setup that governs the system, leave a trail. This matters because the most sensitive action in any security model is a change to the security model, and an environment where permissions can be altered without a record is one where the control layer itself is uncontrolled. The full audit story also extends up into the identity and administration tooling of the surrounding Microsoft platform, where sign-in and administrative activity are captured, which is another reason the identity layer belongs in the ERP security conversation rather than off to the side.

The honest practitioner's note is that logging is easy to switch on and easy to ignore. A log that nobody reviews is evidence after the fact and nothing more; it will help you explain an incident, but it will not prevent or catch one in a timely way. The organisations that get real value from logging are the ones that build a light periodic review, a scheduled look at changes to the most sensitive data and to permissions, so that anomalies surface within days rather than being discovered by an external auditor months later. The technology gives you the record; the value comes from someone actually looking at it on a rhythm.

10. Designing a role model that scales (a practical framework)

Everything to this point has described the mechanisms. This section is about turning them into a design that survives growth and change, because a role model that works for thirty users and falls apart at three hundred was not really a model, it was a lucky arrangement. The framework I use with clients is deliberately simple, because complexity in a security model is itself a risk, and it runs in a repeatable sequence.

• Step 1: enumerate the real roles, not the org chart. Start from what people actually do, the distinct jobs the business contains, not the list of job titles. Two people with different titles who do the same ERP work are one role; one person who genuinely does two jobs is two roles. Aim for the smallest set of roles that honestly describes the work, because every role you define is a thing you will maintain forever.
• Step 2: define each role by its task footprint. For each role, list the tasks it must perform and, just as importantly, the sensitive tasks it must be prevented from performing. The prohibitions are not optional detail; they are half the design, and writing them down now is what lets you check for segregation-of-duties conflicts later.
• Step 3: compose permission sets from tasks, not from tables. Build the access for each role from the capabilities the tasks require, using built-in sets as reference and custom sets where the built-ins are too broad. Name everything consistently so the library stays legible, and resist the urge to create a slightly different set for every minor variation.
• Step 4: assign through groups, never to individuals. Map each role to a security group, attach the permission sets to the group once, and put people into groups. Individual assignment should be the rare, documented exception, not the default, because every direct grant is a future audit finding waiting to happen.
• Step 5: test the model against the prohibitions. Before it goes live, check the combinations. For each role and each user who will hold multiple roles, verify that no forbidden combination of capabilities has been created. This is the segregation-of-duties check, and it is far cheaper to do at design time than to explain to an auditor afterwards.
• Step 6: schedule the review that keeps it clean. A role model is not a one-time deliverable; it is a living thing that drifts. Put a periodic access review on the calendar, quarterly or at least twice a year, in which each role's membership and each exception is re-justified or removed. The review is what turns least privilege from a slogan into a maintained reality.

What makes this framework scale is that it defines access by role once and applies it by membership forever, so growth adds people to existing roles rather than multiplying bespoke configurations. When the business genuinely changes, a new function, a new entity, a restructured team, you add or revise a role, which is a bounded and reviewable change, rather than editing dozens of individual accounts and hoping you caught them all. The whole point of the discipline is that the model stays small and legible even as the user count grows, which is precisely the property that the assembled-under-pressure approach can never deliver. If you are still earlier in the decision, weighing whether the platform fits your control needs at all, the is Business Central right for your organisation pillar frames that assessment, and the complete features guide maps the functional surface these roles will need to cover.

11. Common security mistakes (over-permissioning, orphaned accounts)

Across the environments I have reviewed, the same handful of failures recur with almost tiring consistency, and every one of them is a discipline problem rather than a technology limitation, which is good news because it means the fix is within your control.

• Over-permissioning by default. The single most common finding: users carry broad, near-administrative access that was granted for convenience during go-live and never trimmed. The system did not fail; the tightening that was promised for "after stabilisation" never happened, and the temporary became permanent.
• Orphaned accounts. Accounts of leavers, contractors and long-departed project staff that remain active because deactivation was never wired into the leaver process. Every orphaned account with financial access is an unattended door. Centralising identity in Entra ID and tying ERP access to group membership is the structural fix, but it only works if the leaver process actually runs.
• Shared and generic accounts. A login that several people use, or a generic "finance" account, destroys accountability at a stroke, because the logs can no longer tell you which human did what. Every person who touches financial data needs their own identity, without exception, or the entire detective layer is worthless.
• Segregation-of-duties conflicts created by accident. Access granted capability by capability, without ever checking the combinations, quietly hands one person both halves of a control that was meant to need two. The conflict is invisible until an auditor maps it, and by then it has usually existed for years.
• Direct assignment instead of groups. Permission sets bolted onto individual accounts produce a model where the same role is configured differently on every person, nobody can state confidently what any user can do, and the audit takes weeks instead of hours.
• An unmanaged permission-set library. Custom sets created ad hoc without naming standards or an owner multiply into near-duplicates whose differences nobody can explain, which is just the original chaos wearing a tidier costume.
• No periodic review. Even a good model decays without review, because grants accumulate and revocations do not happen on their own. The absence of a scheduled access review is the root cause behind most of the mistakes above, because it is the mechanism that would have caught them.

The honest caution: none of these mistakes announce themselves. An over-permissioned, orphaned-account-riddled environment runs perfectly well day to day, which is exactly why it persists. The problems are invisible until an audit exposes them or an incident exploits them, and by then the remediation is a painful retrofit under scrutiny rather than a quiet piece of good design. Security debt is the most patient kind of debt, and it always eventually presents its bill.

Final thoughts

Business Central gives you every mechanism you need to build a security model that is both genuinely safe and comfortably workable: delegated identity through Entra ID, licence entitlements as an outer boundary, permission sets as precise building blocks, group-based assignment for scale, layered company, data and field access for fine control, and change logging to prove it all held. The mechanisms are not the hard part. The hard part is the design decisions they enforce, and those are business decisions about your control environment that no partner and no default configuration can make for you.

The organisations whose ERP security I would trust are not the ones with the most sophisticated permission structures. They are the ones that decided their roles deliberately, defined each role by what it must do and must never do, assigned access through groups rather than by hand, and put a periodic review on the calendar that actually happens. That is unglamorous work, and it is the entire difference between a system where you can answer "who can do what" in minutes and one where nobody honestly knows. Security set up in a hurry and never revisited is the default across the industry. Deciding not to be the default is a choice available to any organisation willing to treat it as the design task it always was.

Related reading: The Business Central implementation journey, Business Central and the Microsoft ecosystem, Business Central approval workflows, Is Business Central right for your organisation, Business Central features: the complete guide.