Author: Veli-Pekka Vähälummukka, Program Director, Trivore
The multi-role reality in Nordic organisations
Walk into any large Finnish hospital and you will meet doctors who are also university researchers. Some hold a permanent contract with one hospital, a fixed-term lectureship at a university, and a locum arrangement with another healthcare district — all running simultaneously. Each role carries different access needs: clinical systems for patient care, research databases for their university work, and a separate EHR instance for their locum shifts.
Healthcare is the most visible example, but the pattern repeats across Nordic working life. In education, a teacher may hold a permanent position, substitute for a colleague in another department, and run an extracurricular programme — three relationships with the same employer, each granting different system access. In the public sector, a municipal employee might also sit on a regional board and lead a cross-municipal project, each with its own mandate and its own set of permissions.
This is more common in the Nordics than in many other markets, and the reasons are structural. Strong labour protections mean people accumulate roles rather than replacing them. Fixed-term contracts are widespread in healthcare and education. Municipal governance routinely places the same person in multiple formal positions. The Nordic healthcare staffing model — where specialists frequently work across organisational boundaries — adds another layer of complexity.
For identity and access management, this creates a problem that surfaces every week in operational reality. Which permissions apply when someone holds two active contracts? What happens to system access when one contract ends but two others continue? Most IAM systems treat a person as a single entity with one employment status. When that person leaves one role, the system faces a binary choice: deactivate the identity, or leave everything in place. Neither option is correct.
The default approach in most organisations is to deactivate the person. That kills access across all their active roles. The workaround is to not deactivate — which leaves stale permissions from the ended role sitting alongside legitimate access from the continuing ones. Both paths create operational problems. Both create compliance risk. And both burn IT team hours on manual cleanup that should never have been necessary.
Why flat role models fail
The standard IAM architecture that most organisations run today was designed for a simpler world: one person, one employment, one set of roles. The identity object represents a human. Roles are attached to that identity. An employment status flag — active or inactive — controls whether access is on or off.
This works well enough when each person has exactly one relationship with the organisation. It breaks down the moment that assumption no longer holds.
When a hospital needs to onboard a doctor who already exists in the system as a researcher, IT teams improvise. They create manual role assignments outside the normal provisioning flow. They build exception lists. They grant “temporary” elevated permissions that quietly become permanent because no one owns the review process for them. They flag the account with notes in a spreadsheet to remind someone to check it during the next access review.
These workarounds function in the sense that people get the access they need to do their work. But they create a different kind of problem: the audit trail becomes meaningless. When access was granted through a conversation between a line manager and an IT admin rather than through a rule-based policy, you cannot demonstrate to an auditor why that person has those permissions. You can only demonstrate that someone clicked a button at some point.
Under NIS2 — which is now in force across the Nordics — organisations classified as essential or important entities must demonstrate that access management follows documented policies with traceable audit trails. ISO 27001, which many Nordic organisations use as their baseline, requires the same. A bag of manually assigned roles with no governing logic does not meet either standard.
The consequences are not merely theoretical. In January 2025, a case came to light at HUS in which a doctor had accessed the patient records of his former supervisor without having a patient-doctor relationship with that patient. The case became a criminal matter. Although the root cause was the misconduct of a single individual, it is difficult to ignore the structural issue: why was access granted in the first place? In a well-managed identity model, access to patient data should be tied to an active patient-physician relationship—that is, to a specific agreement—rather than to a broad role that persists even after the specific task for which it was granted has ended.
The HUS case is extreme, but the underlying pattern is routine. In any organisation running a flat role model, some percentage of current access cannot be traced to a current business justification. The larger the organisation, and the more multi-role employees it has, the wider that gap becomes.
Contract-based identity modelling explained
There is an alternative to the flat role model, and it starts with a different foundational object. Instead of attaching roles directly to a person, you introduce a layer between the person and their access: the contract.
A contract, in this context, is a declarative statement of the relationship between a person and the organisation. It is not a legal document — it is a data object that represents a specific role, employment, mandate, or assignment. Each contract carries its own metadata: start date, end date, review dates, organisational unit, and the rules that govern what happens when the contract expires or is terminated.
A single person can hold multiple contracts simultaneously. The hospital doctor from our earlier example would have three: one for their permanent clinical role, one for their university research position, and one for their locum arrangement. Each contract independently governs the access it justifies.
This has several practical consequences that change how identity operations work day to day:
- Parallel contracts. When a teacher takes on a substitute role in another department, a new contract is created. It runs alongside their existing permanent contract. Each contract drives its own set of access grants. There is no collision, no manual override needed, and no ambiguity about why any given permission exists.
- Future-dating. A new hire starting next quarter can have their contract created today. The contract carries a future start date. Provisioning happens in advance — accounts are created, access is staged — but nothing goes live until the contract’s start date arrives. No more first-day scrambles where a new employee sits at their desk waiting for IT to catch up.
- Independent lifecycle. When the locum contract ends, only the access tied to that contract is revoked. The doctor’s permanent hospital contract and their university contract are unaffected. There is no binary on/off decision for the whole identity. Each contract manages its own lifecycle independently.
- Substitution and absence. When an employee goes on parental leave, their contract can be paused and a time-limited substitute contract created for the person covering their duties. The substitute gets exactly the access they need, scoped to the duration of the absence. When the original employee returns, their contract resumes and the substitute’s access expires automatically.
- Access governance scoped to contracts. Role-based access control (RBAC), organisation-based access control (OrBAC), and attribute-based access control (ABAC) all still apply — but they are scoped to contracts rather than attached directly to the person. This means the same person can have different privilege levels in different contexts, governed by different policies, without any contradiction in the access model.
In a production implementation — such as Trivore’s eIAM platform, which uses contract-based modelling as its core architectural principle — contracts are processed by a rule engine that translates them into concrete access grants. Changes propagate through an event bus to downstream systems. The contract is the source of truth; the access grants are derived from it. This means the system can always answer the question: “Why does this person have this access?” The answer is never “because someone requested it three years ago.” It is always “because this active contract requires it.”
Real outcomes
Organisations that have moved to contract-based identity modelling report consistent operational improvements, though the specifics vary by sector and scale.
Faster onboarding for multi-role employees. When a new contract is the only thing needed to grant a defined set of access, onboarding a person into a second or third role takes minutes of administrative work rather than days of IT requests. Future-dated contracts mean the access is ready before the person’s first day.
Clean offboarding without collateral damage. Ending one role no longer triggers a scramble to figure out what else the person still needs. The contract that ended takes its access with it. Everything else stays. This eliminates one of the most common sources of IT escalations: people losing access they still need because someone deactivated the wrong thing.
Traceable audit trails. Every access grant is linked to a contract. Every contract has an owner, a justification, and a lifecycle. Auditors can trace any permission back to the business relationship that authorised it. This is not retroactive documentation — it is built into the operational model.
Reduced manual IT work. The design target for routine joiner-mover-leaver activity is 80% automation. That means the majority of contract creation, access provisioning, access revocation, and contract termination happens without a human touching a ticket. IT teams spend their time on exceptions and complex cases rather than processing routine onboarding and offboarding.
Stronger NIS2 compliance posture. NIS2 requires documented access management policies, traceable decision-making, and the ability to demonstrate that access is proportionate to the business need. A contract-based model provides the structural foundation for all three requirements, because the contract itself is the documented, auditable justification for every permission it grants.
Is your identity model contract-aware?
If you manage identity for a large organisation with multi-role employees, contractors, or complex staffing models, here are five questions worth asking about your current setup:
1. Can your IAM system represent two active employments for the same person without creating two separate identities? If the answer is no, you are either duplicating identities (which creates its own governance nightmare) or forcing multi-role people into a single flat structure that cannot model their actual situation.
2. When one employment ends, does your system revoke only the access tied to that specific employment? Or does it deactivate the entire identity, or leave all access in place because someone is afraid of breaking the other roles?
3. Can you future-date access grants tied to a contract that starts next month? Or does provisioning only happen after someone submits a ticket on or after the start date?
4. Can you model substitute relationships with automatic expiration? When someone covers for a colleague on leave, does the substitute’s access have a built-in end date, or does it persist until someone remembers to remove it?
5. For any given user, can you show an auditor exactly which business relationship justifies each of their current permissions?
If more than one of these questions exposed a gap, the issue is likely architectural. Layering more process on top of a flat role model does not solve it — it adds cost and complexity without fixing the underlying problem.
Contract-based identity modelling is one way to address these gaps structurally. If you want to explore what it would look like in your environment, that is a conversation worth having.