A terminated technician can still reach a building automation workstation. A contractor’s shared remote account remains active after a project closeout. A service account has administrator rights because nobody can confirm what it supports. These are not isolated IT housekeeping issues. They are ownership failures with direct consequences for tenant operations, physical security, life-safety coordination, and business continuity.
This enterprise identity governance guide is for leaders who need access decisions to hold up across offices, telecom rooms, cloud platforms, security systems, and operational technology. The goal is not to make every access request slow or burdensome. It is to establish one standard for who gets access, why they need it, how long it lasts, and who is accountable for removing it.
Identity Governance Is an Operations Control
Identity governance is the discipline of controlling digital access throughout its lifecycle. It answers basic questions that too many organizations cannot answer quickly: Who has access? What can they reach? Who approved it? Is it still needed? What happens when the employee, vendor, project, or system relationship ends?
For a commercial property or enterprise environment, the scope reaches well beyond email and business applications. Identities may control network switches, wireless controllers, video management platforms, access control panels, utility monitoring, building automation servers, backup consoles, cloud administration portals, and remote support tools. A weak access decision at any layer can become an outage, a security incident, or a delayed response when the building needs attention.
The hard part is that responsibility is often fragmented. Facilities may own the vendor relationship. IT may own the network. Security may own cameras and card access. A construction team may provision accounts during a project. A managed provider may administer systems after turnover. Each party can reasonably assume someone else is governing access. That assumption is the risk.
Good governance creates one accountable process even when multiple teams operate the environment. It does not require one person to understand every platform in detail. It requires clear ownership, documented approval paths, and evidence that access remains appropriate.
Start With the Identities That Create the Most Risk
Do not begin by trying to clean up every account in every system at once. Start where unauthorized or unmanaged access would create the greatest operational consequence. For most organizations, that includes privileged administrators, remote vendor accounts, shared accounts, service accounts, and identities connected to critical building or security systems.
Separate people, vendors, and nonhuman accounts
A named employee account, a vendor support account, and a service account should never be governed as if they are the same thing. Each has a different owner, lifecycle, and review requirement.
Named user accounts should map to a specific person and their current role. Vendor accounts should map to a named individual at the vendor, a sponsor inside the organization, a defined scope of work, and an expiration date. Service accounts need an identified business owner, technical owner, documented purpose, known dependencies, and a process for credential rotation.
Shared credentials deserve special attention. They are sometimes unavoidable for legacy building systems or emergency procedures, but they remove accountability. If a shared account must remain, document why, restrict where it can be used, store the credential under controlled access, rotate it after personnel changes, and log its use where the platform allows. “The installer set it up that way” is not a control.
Define critical access by consequence, not department
A camera platform may sit with security. A building automation server may sit with facilities. The network that supports both may sit with IT. Governance should classify access by what failure or misuse would affect, not by which department purchased the platform.
Critical access usually includes systems that can disrupt occupancy, compromise physical security, expose sensitive data, interrupt communications, or prevent recovery during an incident. This classification helps leaders set review frequency and approval standards. A standard office application may tolerate a quarterly review. Administrative access to a core network device or building control server may require more frequent validation and stricter controls.
Build an Access Lifecycle That Works in the Real World
The strongest policy is useless if it depends on people remembering informal handoffs. Identity governance needs a repeatable lifecycle that begins before access is granted and ends with verified removal.
First, require a business reason and a named approver for access. The approver should understand the operational need, not merely confirm that a request arrived. For a vendor, the request should also define the system, access method, hours of work, sponsor, and expiration date. Standing remote access for an undefined future need is convenient, but it creates a permanent control gap.
Next, provision access using roles wherever possible. A role groups permissions around a job function, such as help desk analyst, property engineer, security operator, or network administrator. This reduces one-off permission decisions and makes access easier to review. It also exposes exceptions. When someone needs permissions outside their role, that should be visible, approved, and periodically reconsidered.
Then, establish change events that trigger an access review. Hiring, transfer, leave, termination, contract end, project turnover, system retirement, and vendor replacement should all produce a predictable action. The key is connecting those events to the systems where access exists. A terminated employee may be disabled in the primary directory while retaining access to a standalone appliance, cloud tenant, remote-support portal, or local supervisor workstation.
Finally, remove access and retain evidence. Offboarding should not be treated as complete when one central account is disabled. It is complete when assigned applications, privileged groups, remote access methods, physical credentials where applicable, and locally managed accounts have been addressed. The evidence can be simple, but it must show who completed the action and when.
Use Access Reviews to Find Ownership Gaps
Access certification is often treated as a compliance exercise: send a manager a list, collect clicks, and close the task. That approach produces paperwork without much assurance. A useful review asks an accountable owner to make a real decision about whether access remains needed.
Reviewers need context. A list of usernames is not enough. Show the system, role or privilege level, last use when available, account type, vendor affiliation, sponsor, and expiration date. A facilities director can make a better decision when they see that a vendor’s remote account has not been used for nine months and was tied to a completed controls project.
Set review frequency according to risk. Privileged accounts, remote access, and critical operational technology should be reviewed more often than low-risk business access. The exact interval depends on the environment, staffing model, regulatory requirements, and system capabilities. What matters is that the interval is deliberate and that exceptions have an owner.
When a review identifies an unknown account, do not simply certify it because disabling it feels risky. Investigate its purpose, dependencies, and owner. If it supports a critical process, document that relationship and move it into the normal governance model. If nobody can establish a legitimate need, remove it through a controlled change process. Unknown access is not an acceptable permanent category.
Control Vendor Access Without Blocking Necessary Work
Connected buildings rely on specialized vendors. They may need access to diagnose alarms, support equipment, apply updates, or complete warranty work. Denying all remote access can delay restoration. Granting broad, persistent access creates another kind of exposure. The practical answer is controlled access with clear terms.
Vendor access should be individually attributable, time-bound when feasible, limited to the systems required, and approved by both the operational owner and the security or IT authority responsible for the environment. Remote sessions should be logged where possible. The vendor sponsor should confirm access remains needed at regular intervals, especially after a project transitions from construction to operations.
Project closeout is a common failure point. During construction, contractors may receive elevated access to configure networks, cameras, access control, wireless, or building systems. At final acceptance, those accounts, credentials, configuration files, and administrator roles must be reconciled. Treat identity turnover as seriously as as-built drawings, labeling, test results, and warranty records. A completed installation is not operationally complete if nobody knows who can still administer it.
Measure What Leaders Need to See
A governance program becomes sustainable when it produces a small set of operational measures. Avoid reporting hundreds of technical statistics without context. Leaders need evidence that ownership is improving and risk is shrinking.
Track the percentage of critical systems with a named business and technical owner, the number of privileged accounts without recent certification, vendor accounts past their expiration date, dormant accounts, and offboarding actions completed within the required window. Also track exceptions: systems that cannot support individual accounts, logging, credential rotation, or automated deprovisioning. Exceptions are not failures if they are visible, risk-rated, time-limited, and assigned to an owner.
The most useful metric is often the unresolved-account count: identities that nobody can explain, approve, or confidently remove. That number exposes fragmentation faster than a polished policy document. Drive it down through inventory, ownership, and disciplined follow-through.
Make Governance Part of System Ownership
Identity governance should appear in system design, procurement, project turnover, incident response, and lifecycle planning. Before a new platform is accepted, confirm how accounts are created, how roles are assigned, whether access can be logged, how vendor support works, and how access is removed at end of life. If those answers are unavailable, the system is not ready for accountable operations.
The practical test is simple: when a person leaves, a vendor changes, or an incident occurs, can the organization identify and control access without searching through old emails and calling multiple parties? If the answer is no, the next access review is not paperwork. It is an opportunity to establish ownership before an avoidable access gap becomes an operational failure.