A former employee can lose access to email and still retain a path into the building. A terminated vendor account can remain active in a building automation portal. An emergency administrator login can sit unused for months, with no owner able to confirm who knows the password. These are not isolated IT mistakes. They are ownership failures, and identity access management is where those failures become operational risk.
For commercial properties and enterprise environments, access is no longer limited to office doors and network folders. It reaches cameras, tenant systems, telecom rooms, mechanical controls, cloud applications, remote support tools, Wi-Fi, visitor platforms, and managed services. Each connection can affect uptime, safety, confidentiality, and the ability to recover during an incident.
The problem is rarely a lack of security products. The problem is fragmented responsibility. Facilities controls badges. IT controls user accounts. A contractor manages a specialized system. Security operations sees alerts but does not approve access. No one has the full picture, and no one can prove that access matches current business need.
Identity Access Management Is an Operations Control
Identity access management, often shortened to IAM, is the discipline of deciding who or what may access a system, what they may do there, and how long that permission should remain active. The identity may belong to an employee, tenant contact, contractor, service account, application, device, or external support provider.
That definition sounds straightforward. Its impact is not. A bad access decision can stop at a spreadsheet, or it can reach a life-safety-adjacent building system, expose sensitive tenant information, or give an outside party a route into the corporate network. The consequences depend on the environment and the privileges involved.
For this reason, IAM should be governed like a critical operational control. It needs defined standards, documented ownership, evidence that approvals occurred, and regular testing. Treating it as a helpdesk task creates a gap between the people issuing credentials and the people accountable for the building, network, and business process those credentials affect.
Start With the Access Paths That Can Interrupt Operations
A complete access program does not begin with an application inventory alone. Start with the systems that support daily operations and the paths used to administer them. This is where hidden risk tends to sit.
Consider an engineer who needs remote access to a building control interface after hours. Consider a security integrator who needs to diagnose a camera issue. Consider a network provider accessing an edge device, or a cloud administrator managing tenant-facing services. Each use case may be legitimate. Each needs a defined route, an approved role, a named sponsor, and an end date where the access is temporary.
Map access across four practical categories: people, systems, locations, and vendors. People include employees, tenants, contractors, and temporary staff. Systems include business applications, network equipment, operational technology, cloud consoles, and security platforms. Locations include telecom rooms, data centers, electrical spaces, loading areas, and controlled office zones. Vendors include every party that can remotely administer, physically enter, or change a supported technology environment.
This exercise usually exposes a hard truth: access ownership is scattered across contracts, email chains, old project documents, and individual memory. That is not a sustainable control.
Do Not Forget Non-Human Identities
Service accounts, application connections, shared administrative accounts, and device credentials deserve the same discipline as human users. They often have broad permissions because they were created to keep a system working during implementation. Years later, they remain active because no team feels safe changing them.
That caution is understandable, especially in operational technology. A careless credential change can disrupt a critical integration. But leaving unknown credentials in place is not a safer option. The responsible approach is to document the dependency, identify a technical owner, test the change path, and rotate or retire credentials under controlled conditions.
Shared accounts should be a clear exception, not a normal practice. When a shared account is unavoidable for technical reasons, record who is authorized to use it, where its credentials are stored, when they were last changed, and how activity is reviewed. Accountability disappears when everyone uses the same login.
Build Access Around Roles, Not Individual Requests
The most common IAM failure is granting access one request at a time with no consistent model behind it. A manager asks for a new employee to have the same access as a colleague. A contractor asks for “admin access” to complete a task. Someone approves the request because the work is urgent. Over time, privileges accumulate.
Role-based access changes the question from “What does this person want?” to “What does this job function require?” A facilities director, property manager, network administrator, security analyst, and third-party technician should have defined access profiles tied to their responsibilities. Those profiles should provide the least privilege needed to perform approved work.
Least privilege is not about making work difficult. It is about limiting the blast radius when credentials are misused, compromised, or simply left behind after a role changes. It also reduces confusion during incident response. If an account has a clear role, investigators can quickly determine whether the activity was expected.
There will be exceptions. Construction turnover, emergency repairs, acquisitions, and system migrations often require elevated access for a limited period. Handle those exceptions with a written reason, a named approver, a defined expiration date, and a follow-up review. Temporary access that has no expiration is permanent access wearing a temporary label.
Tie Identity Access Management to the Employee and Vendor Lifecycle
The access lifecycle has four moments that need controls: onboarding, changes, offboarding, and periodic review. Most organizations give attention to onboarding because a new hire cannot work without access. The other three moments create more risk.
When an employee changes departments or takes on a new responsibility, previous privileges may no longer be appropriate. When a vendor completes a project, remote access and physical credentials should be removed unless there is an active support obligation. When a person leaves, access removal must reach every relevant system, not only the primary email account.
The necessary timing depends on the access type. A departing employee with access to finance records, administrative systems, telecom rooms, or building controls may require immediate action. A low-risk account may follow a scheduled workflow. The key is that the rules are defined before a sensitive departure or incident forces a rushed decision.
Vendor access deserves particular scrutiny because it often crosses organizational boundaries. Require each vendor account to have a business sponsor inside the organization. The sponsor confirms the work remains necessary, reviews privileges, and owns the decision to extend or remove access. A contract alone is not an access approval.
Make Reviews Evidence-Based, Not Performative
Access reviews often fail because the reviewer receives a long export of usernames with no context. Faced with hundreds of accounts, they approve everything to finish the task. The record says the review occurred, but the risk remains.
Give reviewers useful information: the account holder, role, system, privilege level, last activity, approving manager, vendor sponsor, and planned expiration date. Flag dormant accounts, administrative roles, shared credentials, and accounts associated with terminated contracts or inactive projects. These are the records that deserve attention first.
Review frequency should match the risk. Privileged administrative access and remote vendor access may need quarterly review or more often. Standard employee access can follow a different cadence. High-churn environments may need automated triggers when employment status, contract status, or role data changes.
A review is only complete when exceptions have an owner and a deadline. If an account cannot be verified, disable it unless there is a documented operational reason to keep it active. The burden should be on retaining access, not on removing an unverified credential.
Connect Physical and Digital Access Decisions
Commercial environments cannot separate physical security from digital access governance. A technician with a key to a telecom room may be able to connect unauthorized equipment. A person with remote access to a camera platform may alter visibility without entering the building. A badge system, visitor platform, network identity service, and contractor register may all describe the same individual differently.
Full integration is not always realistic, particularly in older buildings or mixed-vendor portfolios. The practical objective is consistent governance. Use a common identity record where possible, require the same sponsor for related physical and digital permissions, and make offboarding procedures cover both. At minimum, the facilities, security, and IT teams must know who is responsible for each access domain and how to escalate a gap.
This is also why project closeout matters. New systems arrive with installer credentials, default accounts, support portals, and temporary remote connections. Final acceptance should confirm that these accounts have been transferred, renamed, secured, or removed. A system is not operationally complete because it powers on. It is complete when ownership, documentation, and access controls are accepted.
Assign One Accountable Owner
IAM requires participation from HR, facilities, security, IT, operations, and external providers. Participation does not mean shared accountability. One accountable owner must maintain the standard, resolve disputes, measure compliance, and escalate failures.
That owner does not need to manually approve every request. In a mature program, system owners approve business need, managers confirm role changes, and technical teams administer controls. But the operating model needs one authority that can ask a simple question and get a reliable answer: who has access, why do they have it, who approved it, and when will it be reviewed?
Useful measures are practical: the number of dormant privileged accounts, time to remove access after separation, percentage of vendor accounts with active sponsors, overdue access reviews, and unsupported shared credentials. These measures reveal whether the process is protecting operations or merely generating tickets.
The next time a new system is commissioned, a vendor is engaged, or a project reaches turnover, ask who will own access after the project team leaves. If the answer is vague, the technology is not ready for long-term operation.