Blog

Key takeaways

• IFS Cloud access is built from Permission Sets granted to users - RBAC done well means roles map to job functions, not to individuals.
• Segregation of Duties (SoD) means no single person controls a whole transaction - create versus approve, order versus receipt, master data versus payment.
• The highest-risk SCM conflicts are supplier creation with invoice approval, and PO creation with goods receipt.
• Custom objects can bypass the standard security model - an unsecured projection or event is an invisible SoD hole.
• Design roles around a documented SoD conflict matrix, then audit against it on every change and every release.

IFS Cloud does not grant access to people directly. It grants it to Permission Sets - named bundles of rights over projections, entities and actions - and then assigns those Permission Sets to users. That is role-based access control (RBAC): the permission attaches to the role, the role attaches to the person.

Done well, a Permission Set maps to a job function: “Buyer”, “Goods Receipt Clerk”, “AP Approver”. A user gets the sets their job needs and nothing more. Done badly, sets balloon into “Purchasing” catch-alls that grant every action in the module, and the line between who can order and who can pay disappears.

Two principles keep RBAC honest: least privilege - grant only what the function requires - and role, not person - never patch a one-off permission onto an individual, because it is invisible at the next audit. Everything that follows depends on getting this foundation clean.

Segregation of Duties is the control that stops one person owning a whole transaction end to end. If the same user can create a supplier and approve that supplier’s invoices, they can invent a payee and pay them. If the same user can raise a purchase order and confirm its goods receipt, they can fabricate a delivery that never arrived.

In IFS Cloud SCM the classic separations are:

• Master data vs payment - who creates a supplier is not who approves its invoices.
• Order vs receipt - who raises the PO is not who confirms the goods in.
• Requisition vs approval - who asks is not who authorises.
• Inventory vs reconciliation - who adjusts stock is not who counts it.

SoD is not about distrust. It is a structural control that removes the opportunity, so a single mistake or a single bad actor cannot complete a fraudulent cycle alone.

These are the combinations an auditor tests first. If one user holds both sides, it is a finding - whether or not anyone has abused it.

Build this into a documented conflict matrix before you design a single Permission Set. The matrix is the specification your roles must satisfy - and the checklist every audit will run against you.

Here is the trap that turns a clean RBAC design into an audit failure. Your standard Permission Sets can be perfect, and a single custom object can still route around them. A custom projection that exposes purchase-order actions without inheriting the standard security, a Custom Event that writes an invoice status under a service account, an integration that runs with more rights than any human role - each is an invisible hole in the SoD model.

This is why security and Clean Core are the same conversation. Every extension must be built inside the IFS Extensibility Framework and secured with the same Permission Sets as standard functionality - never with a bypass and never with a shared privileged account. If a custom object can do something a role cannot, your conflict matrix no longer means anything.

Audit your custom objects against the same matrix as standard duties. The Clean Core approach to IFS Cloud SCM exists partly for this reason: update-safe extensions are also security-safe extensions, because they respect the standard model instead of working around it.

A security review that maps your Permission Sets to a documented SoD matrix - standard and custom objects included - turns a future audit finding into a change you made on your own terms. I design and audit IFS Cloud RBAC and Segregation of Duties as an update-safe service, inside the standard model.

Book a 30-minute security call See the security service

Whether you are building fresh or cleaning up a live system, the same sequence works.

1. Document the conflict matrix - agree with finance and audit which duty pairs must never coincide.
2. Define roles by job function - one Permission Set per function, sized to least privilege, mapped to the matrix.
3. Map users to roles - assign only the sets a job needs; remove one-off individual grants.
4. Test for conflicts - check every user against the matrix; a single person holding both sides of any pair is a flag.
5. Secure custom objects - confirm every extension inherits standard Permission Sets and no bypass account exists.
6. Re-audit on change - every new role, joiner or release re-runs the matrix. Tie it into your upgrade routine.

Fold the security re-check into your upgrade preparation so it is never skipped - the IFS Cloud upgrade readiness checklist is the natural place for it. New projections and changed actions in a release can shift what a Permission Set actually grants.

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. Independent practice - you talk to the consultant who does the security work, not a sales layer.

Selected clients: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.

IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.