
Plan an access credential from issue to removal
Create a practical process for approving, issuing, changing, and removing door credentials across staff, visitors, and contractors.
Quick answer: Treat a door credential as a managed assignment with an approver, permitted locations, a start date, and an end or review date. The process should cover changes and removal as carefully as initial issuance, including lost cards, replaced phones, temporary access, and staff departures.
Issuing a badge is easy to see. Removing the access behind an old badge is easier to forget, especially when an employee moves between locations or a contractor returns for another project. A credential program becomes unreliable when those changes depend on individual memory.
The solution is an operating process that the chosen platform can support. Cards, mobile credentials, and other methods each have practical differences, but none replaces clear ownership. Before debating the credential format, decide who can request access, who approves it, and who verifies that the final change took effect.
Separate the person, the credential, and the permission
A person can hold more than one credential, and a credential can be associated with a particular set of permissions. Keep those concepts separate in the working record. A replacement badge should not create an unexplained second identity, and a change of department should not require staff to guess which old access assignments remain appropriate.
Use an authoritative identifier for the person or approved visitor record. Avoid relying only on a display name that another employee may share. Record the sponsor or manager who can answer questions about the assignment, especially for people who are not in the normal employee directory.
Brivo’s credential documentation describes centralized issuance, replacement, updates, and revocation together with role and schedule policies. The practical value of such functions depends on the records supplied to them. A well-organized system cannot decide, by itself, that a contractor’s assignment has ended if nobody owns that fact.
Require an approval that says where and when
An access request should identify the required locations and schedule, not simply ask for “standard access.” Standard groups can be helpful, but their contents must be understandable to the approver. A manager should be able to see whether the request includes a main entrance, a stockroom, another branch, or an after-hours window.
Keep the approval proportional to the access being requested. A routine staff entrance assignment may follow a normal departmental process. A restricted room or unusual schedule may need another owner’s decision. The point is to make the appropriate person responsible, not to create a long approval chain for every replacement card.
Record the start date and the expected duration. If an end date is not appropriate for a permanent employee, use a review date or another defined review trigger. Temporary access should be visibly temporary in the request, so it is not accidentally assigned through the same open-ended group used for regular staff.
Make issuance a short, verifiable handoff
Before issuing a credential, confirm the intended recipient through the organization’s approved process. Record which credential was assigned and how the user receives basic instructions. Those instructions should explain normal use, reporting a problem, and reporting a lost card or phone.
For mobile access, include the supported device and enrollment workflow in the handoff. HID’s mobile identity documentation treats enrollment, provisioning, and revocation as separate operations. That distinction is useful operationally: sending an invitation is not the same event as confirming that the intended person can use the credential at the required door.
Test an appropriate opening with the user or through a controlled acceptance process. Also verify that the assignment does not include an unintended area. A successful entry at the main door establishes one result; it does not prove that every permission attached to the person is correct. Record completion so the next administrator does not have to reconstruct the handoff.
Change permissions when the work changes
A promotion, transfer, or temporary assignment can alter access needs without ending employment. Include those events in the process instead of limiting attention to new hires and departures. Otherwise, a person can accumulate access from every role held over several years.
Ask the new role owner to approve the required set of locations, then compare it with the existing set. Remove access that no longer has an approved purpose. Avoid simply adding the new group and leaving all prior groups in place because that is the fastest action on screen.
For a multi-site organization, explain how local exceptions are handled. A regional manager might need several locations, while a visiting specialist needs only a defined short-term assignment. The mobile credentials and key cards guide helps compare the user-facing methods, but the permission review should remain consistent regardless of whether the person presents a card or a phone.
Handle loss and replacement as one controlled sequence
A replacement request should address the previous credential before a new one becomes routine. Record what was lost or replaced, which identity it belongs to, and the required response. A lost card, a damaged card that is returned, and a new phone can involve different administrative steps.
Use a concise incident record:
- Identify the credential and the person responsible for the request.
- Record the disabling or revocation action required by the platform.
- Confirm the replacement assignment and the permissions carried forward.
- Verify the final state and retain the completion record.
Avoid giving the replacement broader access just because an old assignment is hard to understand. Resolve the uncertainty with the approver. If a controller or site is offline, identify how the change will be verified when connectivity returns and what interim operating response is required. An action saved in an administrator interface should not be treated as proof that every disconnected device has received it.
Give temporary access a visible ending
Contractors, visitors, and temporary staff need a named sponsor and a clear access period. The sponsor should know what happens if the assignment changes or extends. A time limit is useful only when the renewal process does not quietly convert it into permanent access.
In a hypothetical office renovation, a contractor may need a service entrance during approved work hours for a defined project phase. The next phase might involve another area or a different schedule. Review the new requirement instead of extending the original permission indefinitely because the same company remains on site.
Keep shared credentials exceptional and governed by a documented policy if the organization permits them. The business needs to understand what can and cannot be inferred from the resulting records. Issuing individual credentials is not merely an administrative preference when the stated requirement is to connect an event to a specific assigned identity.
Close access with evidence rather than an assumption
Offboarding should begin with a reliable notice from the responsible business process. Identify the effective time, the person handling the access change, and any location-specific coordination needed. Include all credentials associated with the identity, not only the card most recently issued.
The completion record should show which permissions and credentials were removed or disabled, which systems were checked, and any unresolved exception. Collecting a physical badge can be part of the process, but returning an object does not prove that mobile access or another credential was removed. Conversely, an unreturned card should not leave the organization unable to act on its electronic permissions.
Review the process periodically with a small sample of completed changes. Look for missing approvals, duplicate identities, unexplained active credentials, and changes awaiting synchronization. The objective is to find where the workflow breaks down and assign a correction, not to generate a report that nobody has responsibility to resolve.
The takeaway
A credential lifecycle is a chain of accountable decisions: approval, assignment, change, replacement, and removal. The chosen platform should make those decisions manageable, but the business still has to define the authority and evidence behind them. Clear records reduce the chance that yesterday’s access remains active simply because nobody knew who should remove it.
Apply the same discipline across cards and mobile credentials, while documenting the different technical steps each method requires. For a nationwide organization, a common process with named local owners is more useful than a collection of unrelated branch habits. Start with one complete lifecycle and make sure staff can follow it from beginning to end.
Connect policy to the door system
Use the business door access control guide to link credential administration with door behavior, schedules, installation scope, and handover.
FAQ
Does returning a badge finish offboarding? No. Check the person’s electronic permissions and all assigned credentials, including mobile options and other cards. Record the completed removal process rather than relying on possession of one physical object.
Should contractors receive the same access as employees? Only where the approved work requires it. Assign a sponsor, appropriate doors and hours, and a defined ending or review point so the temporary assignment does not become an unexplained permanent permission.
What happens when someone replaces a phone? Follow the credential provider’s supported replacement process, address the old credential, and verify the new assignment. Do not assume that installing an app on another device automatically resolves every prior access state.
Can one process cover multiple brands? The approval and recordkeeping principles can be common, but the technical steps differ. Document the current procedure for each deployed system and verify the outcome at the relevant locations rather than assuming identical behavior.
