The Orphaned Access Problem: Who Owns Building System Accounts?

The Orphaned Access Problem

A building can be operating normally, a maintenance visit can be scheduled, and a technician can be ready to work—until someone asks a basic question: who owns the account required to support the system? In this episode of Built, Wired & Secured, the conversation examines building-system accounts that remain active after the employee, service provider, or project team that created them has moved on.

The issue is not simply whether an unfamiliar account should be kept or removed. A building-related account may support maintenance, monitoring, remote support, commissioning, or a connected operational service. Disabling it without understanding its dependencies could interrupt support. Leaving it untouched can preserve an access relationship that no current team recognizes or reviews.

The practical challenge is ownership: who understands the account, who can approve its continued use, and who can authorize a change when circumstances shift?

Why Account Ownership Becomes an Operations Issue

Building services often span several groups with different responsibilities. Facilities may operate the building automation environment. A service provider may support the system. IT may oversee identity practices. Property management may manage provider relationships and transitions. The owner may ultimately carry the business risk.

One account can sit across all of those responsibilities without belonging clearly to any one of them. That creates a difficult operational question: who has the authority to decide whether changing access is safe?

• A project team may create access during commissioning.
• A control specialist may know what that access touches.
• A provider may use it for maintenance visits.
• A facilities lead may understand why the system matters to daily operations.
• After project closeout, the context may remain only in emails, old folders, or someone’s memory.

None of those actions are necessarily unreasonable on their own. The problem appears when the handoff between them is incomplete. The account remains, but the explanation for its existence disappears.

Do Not Treat Every Unknown Account the Same Way

An unfamiliar account should not automatically be disabled. It may be operationally important, especially when the team is responding to a maintenance need or failed system. At the same time, an unknown account should not be left indefinitely without a documented ownership decision.

The episode recommends controlled discovery: determine what the account supports, what could be affected by a change, and who is accountable for the decision. This approach recognizes two real risks:

• Leaving the account untouched creates uncertainty about access, ownership, and review.
• Removing the account without understanding its dependency can disrupt maintenance or recovery.

During an outage or urgent service event, teams may not have days to reconstruct account history. That is why the discussion separates the immediate operating decision from the longer-term ownership review.

Use Two Tracks During an Urgent Event

When a technician is waiting and the building needs support, the team needs a temporary decision path. The operating organization should already know who can participate in that decision, which may include the facilities lead, an IT or security representative, and the property or business owner depending on the system involved.

During the event, record what is known, what remains unknown, and who accepted the temporary risk. Then give the temporary decision an expiration point. Without that deadline, temporary access can become permanent simply because the immediate problem was resolved and no one returned to the unresolved ownership question.

The second track is the ownership review. Once operations are stable, the team should identify the purpose of the account, confirm the dependency, assign accountable ownership, and document the change process.

What a Useful Ownership Record Includes

The discussion emphasizes starting with purpose rather than a person. A label such as “legacy service account” does not explain enough for the next operator facing a maintenance issue. A useful record should describe what the account supports, when it is expected to be used, and what may be delayed if access changes.

• System or service: Identify the building system, maintenance function, monitoring need, or service relationship involved.
• Business purpose: Explain in plain language why the account exists.
• Operational dependency: Document what could be delayed or affected if the account changes.
• Accountable owner: Name the person responsible for approving the account’s continuing need.
• Approved user or provider relationship: Identify who uses the account or which provider requires it.
• Change authority: Record who can authorize a new account, modification, temporary action, or removal.
• Record location: State where the source of truth is maintained.
• Review trigger: Note when the account must be reconsidered.

The person using an account and the person accountable for it may be different. A provider may need access to perform maintenance, but the operating organization still needs a named party who can approve that access and review it when the service relationship changes.

Review Access When the Business Changes

A fixed review schedule can help, but the episode highlights lifecycle events as especially useful review points. These are moments when teams are already discussing systems, providers, responsibilities, or business risk.

• Provider transitions
• Staffing changes
• Building acquisitions
• Major system updates
• Service renewals

Connecting account reviews to real operational work makes the process more likely to happen. A list without an owner is simply another place for uncertainty to hide. Likewise, a record stored in an old project folder will not help the next facilities lead during a time-sensitive service issue.

A Practical Starting Point

If there is only an hour available this week, begin with a focused inventory of accounts and access relationships that support building operations, maintenance, monitoring, or service delivery. Put a name beside each account—not necessarily the user, but the person accountable for the access decision. Describe the purpose and dependency in plain language, define the approval and change path, and attach review prompts to provider, staffing, and system lifecycle events.

The goal is not paperwork for its own sake. It is to make an access decision understandable before someone has to make it under pressure. Reliable building operations depend on maintained systems, clear responsibilities, and organizational knowledge that does not leave with a project team or service provider.

Who Owns the Account Supporting Your Building?

Many building technology problems do not begin with a failed device, damaged cable, or visible system outage. They begin with a technician needing access and nobody being able to explain who owns the account.

The building may be running. A maintenance visit may already be scheduled. A service provider may be standing by to troubleshoot an issue. Then the team discovers an account that no current employee recognizes. It may have been created during commissioning, used by a former provider, or connected to a project that closed months or years ago.

At that point, the decision is rarely simple. Leave the account active, and the organization preserves access it cannot clearly explain or review. Disable it, and the team may interrupt maintenance or support for a system that is operationally important.

This is the orphaned access problem: building-system accounts that outlive the people, providers, or projects that created them. It is both an operational continuity issue and an accountability issue.

Why Building Accounts Fall Between Teams

Commercial buildings bring together multiple technology and operating responsibilities. Facilities teams may operate a building environment. Service providers may perform maintenance or remote support. IT may manage identity practices. Property management may coordinate vendor relationships and transitions. Ownership may carry the business risk when a decision affects tenant experience, maintenance response, or continuity.

Those groups can all be acting appropriately within their roles while an access relationship still falls between them. One group may know the equipment. Another may know the provider. Another may know the account process. Another may have authority to accept operational risk.

The result is an account with users but no clearly documented accountable owner.

This is especially common after project handoffs. During commissioning or an implementation, everyone involved generally knows who created the access and why it is needed. A control specialist may understand the system dependency. The project team may coordinate the initial provider relationship. Facilities may inherit daily operational responsibility after the project closes.

Over time, people change roles, providers transition, and project records become harder to find. The account remains active, but its history is scattered across emails, work orders, folders, and memory. When a support issue emerges, the team has to reconstruct that context while trying to keep the building functioning.

The Risk Is Not Only Cybersecurity

Unknown access is often discussed as a security concern, and it can be one. But treating it only as a security task misses the operational reality. A building-related account can also be a maintenance dependency, a troubleshooting requirement, and a continuity concern.

When teams cannot identify who can authorize access, several downstream effects appear:

• Maintenance visits can be delayed while teams search for context.
• Troubleshooting can take longer because responsibility is unclear.
• Teams may make temporary decisions without a clear record of accepted risk.
• Provider changes can appear successful even though access ownership was never transferred.
• Tenant-facing comfort or building service issues may take longer to resolve.

The account itself is often not what consumes the day. The search for context does. A team may know that the building is operating, yet still lack a reliable account of which access exists, why it exists, what depends on it, and who has authority to make a decision about it.

Do Not Automatically Disable an Unrecognized Account

When an unfamiliar account appears, the instinct may be to remove it. That response can be understandable, but it should not be automatic. An account that no one recognizes may still support a maintenance workflow, monitoring relationship, remote service need, or operational dependency.

On the other hand, leaving it untouched indefinitely also creates uncertainty. The organization cannot confidently state why the account exists, who is responsible for it, or when it should be reviewed.

The practical response is controlled discovery. Before changing access, determine what the account supports, whether a business or operational dependency exists, who has authority to decide, and what could be affected by a change. The goal is not to preserve every old account. The goal is to make a defensible, informed decision rather than creating a new operational problem while trying to solve another.

Separate the Immediate Decision From the Ownership Review

Urgent events require a different tempo. During an outage or time-sensitive maintenance call, a team may have minutes rather than days to determine a path forward. That is why organizations need two tracks.

The first track is a temporary operating decision for the immediate problem. The operating organization should have a pre-agreed decision path that identifies who can participate in the decision. Depending on the system, that might include a facilities lead, an IT or security representative, and a property or business owner.

The team should document what it knows, what it does not know, and who accepted the temporary risk. Critically, any temporary decision should have an expiration point. Without one, temporary access can become permanent because the system stabilized and the team moved on.

The second track is a documented ownership review after the immediate issue is resolved. That review should not disappear simply because the urgent maintenance need has passed. It should identify the account’s purpose, document its dependency, assign accountable ownership, and define a future review or change process.

Build an Ownership Record That Helps the Next Operator

A useful access record starts with purpose, not merely an account name. “Legacy service account” gives the next operator almost no information. A record should say what the account supports, when it is used, and what may be delayed if the access changes.

For each building-related account or access relationship, document the following:

• The system or service involved.
• The business purpose in plain language.
• The operational dependency and likely impact of a change.
• The accountable owner who approves continued need.
• The approved user, employee, or provider relationship.
• The person authorized to approve a new account, modification, temporary action, or removal.
• The location of the source-of-truth record.
• The event or date that should trigger a review.

It is important to distinguish between the person using access and the person accountable for it. A provider may use the account for maintenance, but the operating organization should know who can approve its continued need and who will revisit the decision when the service relationship changes.

Use Lifecycle Events as Review Triggers

A recurring review schedule can be useful, but lifecycle events are often more effective triggers because responsibility is already being discussed. Provider transitions, staffing changes, building acquisitions, major system updates, and service renewals all create a natural reason to ask whether access remains necessary and properly owned.

Consider a provider change. The outgoing provider may have been able to operate the building system, and the incoming provider may also be able to operate it. At first, the handoff can look complete. But if the incoming team later finds several legacy support identities without a documented owner or service purpose, a maintenance visit can still be delayed while authorization is clarified.

The lesson is not to assign blame to the outgoing provider. A handoff is not complete simply because the new team can log in. A complete handoff means the operating team understands what access exists, why it exists, what depends on it, and who is accountable for reviewing it from that point forward.

Start Small and Make It Usable

Organizations do not need to solve every historical access question in a single project. Start with a practical inventory: accounts and access relationships that support building operations, maintenance, monitoring, or service delivery.

For each entry, assign accountable ownership and write the purpose in language a future operator can understand. Define the change path: who approves a new account, who confirms continuing need, who coordinates with providers, and who records the decision. Those roles can belong to different people, but they cannot belong to nobody.

Keep the record in a source of truth that the operating team can actually find and use. Documentation stored in an old project folder does little for a facilities lead facing an active maintenance issue. Documentation is part of operational maintenance because it preserves the context needed to make sound decisions.

The objective is not paperwork for its own sake. It is reliable operations. Clear ownership helps organizations make access decisions before they become urgent, reduce avoidable delays, and preserve continuity when people, providers, and systems change.

For a practical discussion of this issue, listen to this episode of Built, Wired & Secured. It offers a vendor-neutral framework for finding building-related access, assigning accountability, documenting purpose and dependencies, and reviewing records before uncertainty becomes an emergency.