Independent IFS Cloud practice · Security & compliance
Permission sets and segregation of duties in IFS Cloud: turning an audit liability back into a working access model
Key takeaways
- Permission bloat is a mechanical consequence of cloning: a clone copies every grant the source held, including the ones the source should no longer have, and nothing in the copy records why any individual grant exists.
- An access model an auditor can follow is built from functional roles and a shared base profile, because that structure lets you answer “why does this person hold this grant” from the model rather than from the person’s employment history.
- Hiding a field in Page Designer removes it from the screen and leaves it in the projection, so a user who can reach the projection over OData can still read it. Security is enforced at the projection, not at the page.
- Segregation of duties is a property of the grant model, not of a policy document: if one user holds both the supplier-creation and the payment-authorisation grant, the control does not exist regardless of what the policy says.
- Fewer, deliberately named permission sets shorten onboarding and make Evergreen releases predictable, because you can list which roles a new or changed projection touches.
Security debt in an ERP behaves like any other technical debt: cheap to create, invisible while nothing goes wrong, and expensive at exactly the moment you need it to be clean. In IFS Cloud it accumulates as permission sets that were cloned rather than designed, as administrative grants issued to unblock a go-live and never withdrawn, and as access decisions recorded nowhere except in the grant table itself. The system keeps working. The audit is where the bill arrives, because an auditor does not ask whether users can do their jobs. They ask you to demonstrate that users cannot do anything else, and a cloned set cannot answer that question.
This article covers where the bloat comes from at the object level, how to build an access matrix that satisfies ISO 27001 and SOC 2 evidence requirements, why mobile and field service is the place where a page-level control quietly stops being a control, and what a clean model returns to the business once it exists. It is the security counterpart to the wider argument about keeping the core clean in IFS Cloud: in both cases the question is not whether something works today, but what it costs you at the next release and at the next review.
1.Where permission bloat actually comes from
A cloned permission set inherits every grant its source held at the moment of the clone, with no record of which of those grants the source genuinely needed. That is the whole mechanism. When a new buyer joins and an administrator clones the set belonging to a buyer who has been with the company for nine years, the new starter receives the access that buyer accumulated across three role changes and one go-live where somebody needed temporary rights to finish loading data. Nothing in the clone marks which grants were deliberate.
Repeat this over a few years and the estate stops being a model and becomes sediment. Two sets with near-identical names diverge by grants nobody can explain. A set named after a job title no longer matches what anyone holding that title does. The practical test is short: pick any grant on any permission set and ask which business process requires it. If the honest answer is “it was on the set we copied from,” the model has already failed.
What this costs under Evergreen
IFS Cloud releases change projections, and a permission set is a set of grants against projections. When a release splits a projection, renames an action or introduces a new security checkpoint, a permission set built from a deliberate list of required projections can be assessed against that change in an afternoon. A set carrying hundreds of inherited grants cannot, because nobody can separate the grants that must be re-checked from the ones that were never needed in the first place. This is the same dynamic covered in the IFS Cloud upgrade readiness checklist, applied to security rather than to code: the work an upgrade costs you is decided by how much of the estate you can still explain.
The review finding, almost every time: the defect is not a wrong grant. It is an estate where nobody can say whether a grant is wrong, which makes every grant unverifiable and the model as a whole unauditable.
Standing administrative access
Full system access granted to solve a specific problem tends to persist, because removing it requires someone to determine what the holder actually needs, and that determination is work nobody is assigned. Two consequences follow. A compromised credential on such an account exposes the full data estate rather than one process. More often the audit finding, though, is the second: the account defeats every segregation control at once, because a user holding administrative rights satisfies both sides of any conflict pair by definition. The same concentration problem appears organisationally when knowledge and access both sit with one person, which is why access reviews and succession planning tend to surface the same names.
2.Building an access matrix an auditor can follow
The principle of least privilege becomes demonstrable only when access is derived from business processes rather than from individual people. An ISO 27001 or SOC 2 reviewer does not test whether your access is minimal in the abstract. They ask you to produce, on request, the rule that granted a specific right to a specific person. That is a question about structure, and a structure has to be designed before it can be evidenced.
Step 1: map permissions to processes, not to people
Start from the functional roles the business actually runs: accounts payable clerk, purchasing buyer, warehouse supervisor, maintenance technician, credit controller. For each role, list the projections, pages and actions the process genuinely requires, and build a permission set containing those and nothing else. Naming is what makes this survive contact with the next administrator: a set named after the process it enables can be audited against that process, while a set named after a department or a person cannot. Mapping the process first is the same groundwork that centralised purchasing in IFS Cloud depends on, and in practice the two exercises inform each other, because a process you cannot describe is a process you cannot scope access to.
Step 2: separate the base profile from the role
Every user inherits one global base set covering access that carries no segregation risk: the employee lobby, basic document access, personal time reporting. Everything process-specific lives in the functional role layered on top. This separation does the audit work for you, because it turns “why can this person see this” into a two-line answer: either the access is in the base, which applies to everyone and is reviewed once, or it is in a named role, which maps to a documented process. Without the split, every user is a separate investigation.
Step 3: define the conflicts explicitly
Segregation of duties is enforced by the grant model or it is not enforced at all. The control most often needed in IFS Cloud is that the user who can create or modify a supplier cannot also authorise a payment to one, because those two rights together are sufficient to route money to an account the holder controls. Other standard pairs: entering a supplier invoice and posting to the general ledger; adjusting stock and approving a shipment; changing employee master data and running payroll.
Write these pairs down as a conflict matrix before designing the sets, then test the finished model against it by listing the users who hold both sides of each pair. IFS Cloud provides permission set grant reporting that supports this analysis. Whether conflict detection runs continuously in your specific release and configuration, rather than on demand, is worth confirming in your own environment before you present it to an auditor as a live control. [VERIFY]
| Audit requirement | Where it is implemented in IFS Cloud | Evidence you hand the auditor |
|---|---|---|
| Identification | IAM integration with the corporate identity provider | SAML / Entra ID sign-in logs |
| Authorisation | Projection-scoped permission sets, assigned by functional role | Permission set grant reports, plus the role-to-process mapping |
| Segregation of duties | Conflict matrix applied to the grant model | List of users holding both sides of each defined conflict pair |
| Accountability | History log configuration on the entities in scope | Audit trail of record changes with user and timestamp |
| Review cadence | Scheduled recertification of roles and their holders | Dated review records naming the approver |
The rightmost column decides how the audit goes. A control you perform but cannot evidence counts as a control you do not have, which is why the recertification row belongs in the table even though it produces no technical artefact. The same evidence discipline governs data modelling and data governance in IFS Cloud, and both reviews come back to one question: who is allowed to change what, and how would you prove it after the fact.
3.Mobile access, and why hiding a field is not securing it
Field service is where access design meets its hardest constraint: a technician at a customer site needs enough of IFS Cloud to complete a work order, on a device that may be offline, without carrying any route into financial or HR data. The most common way this goes wrong is subtle enough to survive user acceptance testing intact.
Page Designer hides, projections secure
Removing a field in Page Designer changes what the client renders; it does not change what the projection returns. If the underlying projection still exposes the field and the user still holds the grant, the value remains retrievable through a direct OData request, which is a supported interface rather than an exploit. Any control existing only on the page is therefore cosmetic. The rule that follows is short: decide what a role may read at the projection, and treat page layout as a usability decision taken afterwards.
Verifying this belongs in your test plan rather than in a security review eighteen months later. Take a test account carrying only the mobile role, call the projection directly, and confirm the response contains no field that role is not entitled to. That check fits naturally into the approach set out in IFS testing from a technical perspective, and it rests on the same projection-level reasoning behind monitoring IFS Cloud over read-only OData: what the API returns is the real boundary.
Offline caching moves the boundary onto the device
Data synchronised to a mobile device for offline use sits outside the IFS Cloud security perimeter for as long as it stays there. Two design decisions follow. Scope the cache to what the assignment requires, typically the open work orders with the parts and customer detail attached to them, rather than mirroring a broader data set for convenience. And keep revocation central: when someone leaves, disabling the identity in the corporate directory has to end access everywhere, which only holds if authentication genuinely runs through IAM and no local credential path exists alongside it.
Leaver handling is the control most often assumed rather than tested. Run it once as an exercise with a real test identity, at the point described in go-live as a risk handover, because a revocation path that has never been executed is an assumption rather than a control.
4.What a clean permission model returns to the business
A designed access model makes onboarding an assignment rather than an investigation. A new accounts payable clerk receives the base profile and the accounts payable role and is working the same day, because the decision about what that role may do was taken once and recorded. Under a cloned estate the same request begins with somebody trying to reconstruct what a comparable user has, which is how the estate grew in the first place.
- Predictable releases - when a release changes a projection, a role-to-projection map tells you which roles need retesting, instead of requiring a full regression pass across security.
- Audits that end - evidence assembled from the model rather than reconstructed per user turns a recurring multi-week exercise into a report.
- Lower maintenance - a smaller number of deliberate sets is less work to hold in your head than a larger number of accidental ones, and the difference compounds with every new starter.
- Automation you can trust - workflow and business process automation inherits the access model it runs under, so an automated step built on an over-permissioned account extends that exposure rather than containing it.
There is an organisational dimension too. Tightening access changes what people can do on their own authority, and a rollout presented purely as a control exercise meets resistance that a rollout presented as role clarity does not. That tension is worth planning for deliberately: balancing accountability against team morale treats it as the delivery problem it is, and the brutal truth about IFS implementations sets out why this class of work is usually deferred until an external deadline forces it.
One sequencing note worth stating plainly: permission design belongs before migration, not after it. User and role data loaded into a model that has not been designed carries the source system accumulated access straight into the new environment, which is how a fresh implementation arrives on day one already holding security debt. The IFS Cloud data migration plan is the right place to fix that ordering.
5.Frequently asked questions
How does IFS Cloud security differ from IFS Applications 10?
IFS Cloud secures access at the projection, the unit that the OData provider and REST APIs expose, whereas IFS Applications 10 relied more heavily on database-level access. The practical consequence is that a permission set in IFS Cloud is a set of grants against projections and their actions, so securing the API surface and securing the user interface become the same exercise rather than two separate ones.
Can Azure AD (Entra ID) manage IFS Cloud roles?
IFS Cloud IAM integrates with Entra ID for authentication, so sign-in, multi-factor policy and account disablement are handled by the corporate identity provider. Authorisation stays inside IFS Cloud: permission sets define which projections and actions a user may reach, and that granularity has no equivalent in the directory. The split matters for leaver handling, because disabling the directory account ends access only if no separate local credential path exists alongside IAM.
What does the principle of least privilege mean in an ERP context?
Least privilege means each user holds the minimum access their documented job function requires, and nothing carried over from a previous role or a temporary need. In an ERP it limits both deliberate misuse and accidental damage, because a user who cannot reach a process cannot corrupt its data. It is also the assumption an ISO 27001 or SOC 2 reviewer tests directly, by asking which rule granted a specific right to a specific person.
If a field is hidden in Page Designer, is it secure?
No. Page Designer controls what the client renders, not what the projection returns. A field removed from a page stays retrievable through a direct OData request if the projection still exposes it and the user still holds the grant. Security has to be enforced at the projection; page layout is a usability decision taken afterwards.
Which segregation of duties conflicts should be defined first?
Start with the pairs where a single holder is sufficient to move money or stock without a second party: supplier creation combined with payment authorisation, supplier invoice entry combined with general ledger posting, stock adjustment combined with shipment approval, and employee master data changes combined with payroll execution. Define the pairs before designing permission sets, then test the finished model by listing the users who hold both sides of each pair.
How long does a permission set redesign take?
Duration is driven by how many distinct functional roles the business runs and how many modules are in scope, not by user count, because the design work happens once per role and assignment is fast afterwards. A redesign covering process mapping, conflict matrix definition, set construction and user acceptance testing typically runs four to eight weeks. The longest step is usually agreeing what each role is permitted to do, which is a business decision rather than a technical one.
6.About the author
Dariusz Myśliwiec: 25+ years in ERP and supply chain, 17+ on IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally through an independent practice.
Selected clients: Fugro · LGC · BVI Medical · Betafence · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
Not sure whether your permission sets would survive a review?
The fastest way to find out is to pick one conflict pair, such as supplier creation and payment authorisation, and list the users who hold both sides. If producing that list takes more than an afternoon, the estate is the problem rather than the query. A short technical call is usually enough to scope what a redesign would involve in your environment.
