Vendor and contractor access: the guest accounts nobody owns

Count them

Run a count of guest users in your tenant. Not active guests — all guests. Then two questions per account: who invited it in, and has that person signed in during the last ninety days?

In Norwegian energy companies with normal project activity, the number of guest accounts typically ranges from several hundred to a few thousand. The proportion that hasn't been used in the last three months is high. The proportion where the inviter still works at the organisation and still knows why the invitation was sent is lower than management assumes.

This isn't sloppiness. It's a feature of the system. Microsoft Entra B2B is designed to make guest invitation easy and decentralised — that's the whole point. The invitation takes twenty seconds. The revocation has no owner.

Why this hits critical infrastructure harder than other industries

A software company with a hundred employees might have ten suppliers with system access. A grid company has contractors on line work, a supplier for every single system platform, consultants on a modernised customer information system, auditors, meter suppliers, an OT vendor per facility type, and a preparedness agreement with a couple more. An offshore operator additionally has a drilling contractor, a well services company, a supply base, a rig owner and a dozen specialised service providers — each with their own turnover.

Three factors make this a regulatory risk, not just a hygiene challenge:

§ 6-7 of the Power Supply Preparedness Regulations (kraftberedskapsforskriften, FOR-2012-12-07-1157) requires background checks before employment, and provides a legal basis for requiring credit checks for individuals who are to have access to facilities and systems in class 2 and 3. An entity in the Norwegian power supply contingency organisation (KBO) that cannot produce a precise list of external identities with access to such systems also cannot document that the requirement is met for all of them.

§ 69 of the Undertakings Security Regulations (virksomhetsikkerhetsforskriften) regulates authorisation of supplier personnel for undertakings subject to the National Security Act, and § 72 requires the undertaking to maintain an overview of authorised personnel. That overview has to be real, not approximate.

§ 7-10 of the Preparedness Regulations requires an up-to-date list of approved users for external connection to the operational control system. "Up-to-date" is a requirement about state, not about intent.

Once NIS2 is eventually implemented in Norwegian law, supply-chain security will enter as an explicit requirement under Article 21(d), including an assessment of vulnerabilities at each direct supplier. Point (i) requires access control policies and personnel security. Together, this makes supplier identities a documentation requirement, not just a good idea.

The five failure modes

The guest who outlived the project. The project ended in 2023. The guest account is still a member of three Teams and still has read access to a SharePoint site containing network documentation. No one has had the job of cleaning up, because the project's cost centre was closed.

The contractor who got hired. The person first received a guest account, then an ordinary employee account. The guest account was never removed. Two identities now exist for the same person, and any future offboarding will only catch one of them.

The supplier's shared account. "support@supplier.no" was invited in as a guest because it was easier than dealing with four named people. Now an unknown number of people at the supplier can authenticate as the same identity, and the incident log can never tie an action to a human being. This directly breaches the Norwegian National Security Authority's (NSM) Basic Principle 2.6.1, which requires traceability to the responsible person.

The guest who invited guests. The default configuration in many tenants allows guests to invite other guests themselves. The population then grows without any internal person having made a decision.

The service account with the supplier's password. An integration was set up by a supplier in 2019 using a user account instead of an application identity. The password sits in the supplier's documentation. The account is excluded from MFA because "it breaks the integration". As of 1 October 2025, Microsoft has rolled out mandatory MFA for Azure CLI, Azure PowerShell, IaC tools and REST endpoints on write operations as well, with an explicit recommendation to migrate such user-based service accounts to workload identities. Accounts that haven't been migrated are going to fail — the question is whether they fail under controlled conditions or during an incident.

Colonial Pipeline is still the best illustration

The attack in May 2021 began with a VPN account whose password existed in a leaked password list. The account had no multi-factor authentication, and the profile was an old VPN profile no longer meant to be in use. That's the whole story of the entry point. Everything else — the ransomware, the pipeline shutdown, the fuel shortages along the East Coast — is a consequence of one unused account being allowed to keep existing.

The lesson generalises: the risk isn't that the supplier has access. It's that the supplier still has access after the need has ended, without anyone having made a decision about it.

The four settings that determine how big the problem gets

Before buying anything, there are four configuration choices in Entra ID that determine how fast the guest population grows. They're free to change, and in most tenants at least two of them are still set to the default from the day the tenant was created.

Who can invite guests. The default setting in many tenants allows all members to invite, and in some cases lets guests invite further. Tightening this to a defined group is the single change with the biggest effect — provided there's a working, fast route for those who actually need to bring a supplier in. Without that route, the tightening gets bypassed with shared accounts, which is worse.

Cross-tenant access settings. Organisations increasingly collaborate directly between tenants. The default configuration is often more open than the organisation thinks, and it's rarely reviewed after it was set.

Whether guests can read the directory. A guest with standard read access can, in many tenants, enumerate users and groups. For an organisation where the structure of operational staff is itself power-sensitive information under § 6-2, this is something that should be assessed explicitly.

Guest lifecycle settings. Entra has built-in mechanisms for guest access expiry, but they don't activate themselves, and parts of the governance functionality require an Entra ID Governance licence.

The point of this review isn't that configuration replaces governance. It's that an organisation that hasn't taken a position on these four points also doesn't have a realistic picture of how big the job is.

What has to be in place

A working supplier access model has five properties. None of them are technically demanding; all of them are organisationally demanding, which is why they're missing.

1. Every external identity has a named internal owner. Not a department — a person. The owner is responsible for the access still being necessary.

2. Every external identity has an expiry date. The default should be short — 90 days is a reasonable starting point — with extension as an active action requiring justification.

3. No shared accounts. An action must always be traceable to a human being. That's not a preference, it's the content of NSM's Basic Principle 2.6.1.

4. Invitation is a governed action, not a self-service function. A project manager should be able to request that a supplier representative be given access. The decision to grant it should sit somewhere it gets recorded.

5. The population can be counted at any time, without project work. If answering "how many external users have access to class 2 and 3 systems" takes a week, the answer in practice is that the organisation doesn't know.

How Entra Logic addresses this

The model in Entra Logic hits points 1, 4 and 5 directly and structurally.

Because every change goes through a request–approve–execute flow, inviting an external identity is an order with justification, requester, approver and execution result in the same record. There's no side path where someone invites someone else because it was faster. Because the synchronisation service maintains a continuously updated copy of the entire estate, counting the external population is a search, not a project. And because continuous cleanup checks surface unowned records and unclassified records, the mess becomes visible continuously instead of quarterly.

The delegation model is relevant here: a project manager or a buyer can send the request for supplier access without ever gaining administrator privileges in the directory. That removes the main argument for why guest invitation is a self-service function today — namely, that the alternative was giving more people privileges they shouldn't have had.

Two clarifications about scope. Entra Logic does not perform background checks or personnel screening; it shows which identities the screening should apply to. And it does not run attestation campaigns where owners periodically confirm access; that functionality sits in products in a different category, including Microsoft's own Entra ID Governance, which requires its own licensing tier.

Sources

• The Power Supply Preparedness Regulations (FOR-2012-12-07-1157), §§ 6-7, 7-10 — https://lovdata.no/dokument/SF/forskrift/2012-12-07-1157
• The Undertakings Security Regulations (FOR-2018-12-20-2053), chapter 12, §§ 69 and 72 — https://lovdata.no/dokument/SF/forskrift/2018-12-20-2053
• NSM, Basic Principles for ICT Security v2.1, measures 2.6.1–2.6.3 — https://nsm.no/getfile.php/1313975-1717589722/NSM/Filer/Dokumenter/Veiledere/NSMs%20Grunnprinsipper%20for%20IKT-sikkerhet%20v2.1.pdf
• Microsoft, Plan for mandatory Microsoft Entra multifactor authentication — https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mandatory-multifactor-authentication
• Bloomberg on Colonial Pipeline — https://www.bloomberg.com/news/articles/2021-06-04/hackers-breached-colonial-pipeline-using-compromised-password
• NIS2 Article 21 (secondary source, should be checked against EUR-Lex) — https://www.nis-2-directive.com/NIS_2_Directive_Article_21.html