Access after departure in a rotation and shift organisation

Offboarding is not what you think it is

Ask an IT manager what happens when an employee leaves, and the answer is usually: "the account gets deactivated." That's usually true. It's also about a quarter of the job.

What gets deactivated is authentication. What stays behind is the authorisations and the derived access:

• Delegated mailbox access the person had to a shared mailbox or a manager's calendar.
• Membership in security groups that control access to line-of-business systems, file areas and remote access.
• Guest accounts in other organisations' tenants, created against our email address.
• Guests that this person invited into our tenant, whose purpose nobody else knows.
• One or more devices that were never reset or removed from Intune and Autopilot.
• Ownership of groups, apps and teams, now orphaned.
• Access in systems that aren't connected to the directory at all — the operational control system, a local maintenance system, a supplier portal subscription.

None of these disappear when the account is deactivated. Several of them survive even when the account is deleted.

Why rotation organisations have it worse

In an office organisation with fixed staffing, a departure is a distinct event: last working day, exit interview, checklist. In offshore and shift organisations, every one of these assumptions breaks down.

Absence looks like departure. A person on a two-weeks-on, four-weeks-off rotation is away for four weeks at a stretch. A person on a 14/28 pattern is away longer. Automatic rules that deactivate accounts after X days of inactivity are therefore either too aggressive or switched off entirely — and in practice they're always switched off.

Staffing is mixed. On a typical installation, the operator's own employees work alongside the drilling contractor's people, the well service company's specialists, a crane supplier's technician and an inspector. Several of them need access to the operator's systems. None of them are in the operator's HR system.

Departure is not reported to IT. When a person at a subcontractor is no longer scheduled on the rotation, the supplier's own HR is told. The operator's IT department is not. The identity in the operator's tenant stays active until someone happens to notice it.

Temporary cover multiplies identities. In case of illness, a temporary replacement is brought in on short notice. The replacement gets access "temporarily." The temporary arrangement has no expiry mechanism.

The result is an identity population that grows monotonically, where the share of active identities that actually correspond to a person with a real need shrinks over time.

The regulatory angle

For petroleum activities, it's worth reading § 22 of the Management Regulations on nonconformity handling in this context. The provision requires registration, follow-up, root cause analysis and corrective or compensating measures in the event of a nonconformity. A leftover access arrangement after an employment relationship has ended is a nonconformity against the organisation's own governing documents. The question a supervisory authority asks is not whether nonconformities occur — they always do — but whether the organisation discovers them, registers them, and understands the cause.

§ 11 of the Framework Regulations, "Principles for risk reduction," requires selecting the best available solutions and builds on a precautionary principle. A manual checklist that assumes a person remembers seven downstream measures is not the best available solution in 2026, and it will be hard to argue that it is.

For entities in the Norwegian power supply contingency organisation (KBO), the relevant link is § 7-4 of the Power Supply Preparedness Regulations (kraftberedskapsforskriften, FOR-2012-12-07-1157): control arrangements for granting, changing and deleting user access, reviewed at least annually. Deletion is explicitly mentioned. And for organisations subject to the National Security Act (sikkerhetsloven), § 74 of the Undertakings Security Regulations (virksomhetsikkerhetsforskriften) mandates revocation of authorisation — a requirement that presupposes you know what the authorisation actually covered.

What GDPR does to the arithmetic

A point rarely raised: retaining access to personal data after the role that justified the access has ended is itself a compliance problem for the data controller, regardless of whether the access is misused. The data minimisation principle applies to access rights too, not just storage.

Practical implication: a systematic removal process is something you can show to a supervisory authority and in nonconformity handling. A routine that relies on someone remembering is not.

Why it isn't already solved

Four structural reasons, not four excuses.

The signal is missing. IT doesn't know a contractor has left, because no process routes that information there. This is an organisational challenge that no software solves alone — but it can be made visible by giving every external identity a named internal owner and an expiry date, so that the absence of a signal itself triggers an action.

The action requires privileges few people have. Removing delegated mailbox access, cleaning up group memberships and resetting a device requires, in practice, several administrator roles. So the task lands with a small number of people, who have it queued up.

The task is invisible. Deactivating an account is one action a person performs. The seven downstream consequences aren't represented anywhere as a list.

Nobody measures it. Few organisations have a figure for how many identities are active without a valid basis. Without a figure, the problem doesn't exist in leadership's reality.

The technical checklist that actually has to be carried out

For an offboarding to be complete in a Microsoft-based environment, at least the following has to be handled. The list is worth comparing against your organisation's own routine, because most routines cover the first three points and stop there.

1. Deactivate the account and revoke active sessions and refresh tokens — deactivation alone does not immediately end an ongoing session.

2. Remove or reset registered authentication methods.

3. Handle the licence assignment, which otherwise keeps costing money.

4. Review and remove membership in security groups, distribution groups and teams.

5. Transfer ownership of groups, teams, apps and resources where the person was sole owner.

6. Remove delegated mailbox access, "Send As" and "Send on Behalf Of" rights, both where the person was the recipient of the delegation and where others were delegated in to them.

7. Handle devices: remove from Intune, consider a reset, and clean up the Autopilot registration.

8. Identify and deactivate guest accounts the person themselves invited in, where the purpose was tied to their work.

9. Identify guest accounts the person holds in external tenants under the organisation's email address.

10. Trigger a signal to systems outside the directory — operational control system, line-of-business systems, supplier portals.

Ten points. In a manual process they require four to six different administrator roles and a corresponding number of consoles. That's why they're rarely carried out in full, and that's why they should be one operation.

What Entra Logic changes

Four mechanisms address this directly.

Continuous synchronisation gives a reference state. Because the whole estate — users, groups, devices, Intune, Autopilot, mailboxes, apps and licences — is kept continuously up to date and searchable, the question "what does this person actually have" is one lookup, not seven consoles. That's the difference between an offboarding that takes three minutes and one that takes an hour and is still incomplete.

Offboarding becomes one order with several executed actions. The decision to end an identity, the justification, the approval, and all the technical actions that follow from it, are the same record. That's also what lets you later prove what was actually removed — not just that the account was deactivated.

Delegation moves the initiative to where the knowledge is. A platform manager, an offshore lead or a contract owner can send the request to end an identity the moment they know a person is coming off the rotation — without being granted administrator privileges. The signal originates where the information exists.

Continuous cleanup checks make the backlog visible. Orphaned devices, unowned Autopilot registrations and unclassified records surface as a short, ongoing work list. The goal is a list that is short because it is worked often, not a pile that grows until the next review.

Be precise about the boundaries: the scope of which derived access is captured automatically — in particular mailbox delegation and guest access the departed person created themselves — should be confirmed concretely against the product in a technical review before it's relied on in a risk assessment. And Entra Logic does not touch access in systems outside the Microsoft estate; for the operational control system, it still takes a human or an integration to act on the signal.

Four numbers to get before the next management meeting

1. The number of active identities in the tenant that have not authenticated in the last 120 days. (120, not 90 — the rotation shouldn't produce false positives.)

2. The number of guest accounts without a registered internal owner.

3. The number of devices in Intune without a primary user.

4. The median time from last working day to completed removal of all access, for the ten most recently ended employment relationships.

Number four is the one nobody has. Getting it is usually the cheapest way to get the rest of the work funded.

Sources

• Havtil, the Management Regulations § 22 (nonconformity handling) — https://www.havtil.no/globalassets/regelverk/gjeldende-regelverk-2022/styringsforskriften_n.pdf
• Havtil, the Framework Regulations § 11 (principles for risk reduction) — https://www.havtil.no/en/regulations/all-acts/the-framework-regulations3/II/11/
• The Power Supply Preparedness Regulations (FOR-2012-12-07-1157) § 7-4 — https://lovdata.no/dokument/SF/forskrift/2012-12-07-1157
• The Undertakings Security Regulations (FOR-2018-12-20-2053) §§ 72 and 74 — https://lovdata.no/dokument/SF/forskrift/2018-12-20-2053
• the Norwegian National Security Authority (NSM), Basic Principles for ICT Security v2.1, measure 2.6.2 (account lifecycle) — https://nsm.no/getfile.php/1313975-1717589722/NSM/Filer/Dokumenter/Veiledere/NSMs%20Grunnprinsipper%20for%20IKT-sikkerhet%20v2.1.pdf