Credential Lifecycle in Access Control: Issuance and Revocation

Credential lifecycle in access control: issuance, changes, expiration, revocation, audit, integrations, and engineering criteria.

Confira!

The credential lifecycle in access control is the set of processes that governs a credential from request and issuance through modification, suspension, revocation, expiration, replacement, and disposal. Managing credentials is therefore not limited to registering cards or users: each identity must retain only the privileges compatible with its relationship, role, location, schedule, and risk level throughout the period in which those privileges are valid.

The central issue is temporal. A credential can be correctly issued today and become inappropriate tomorrow because the person changed role, site, employer, shift, project, or relationship status. Likewise, a lost, copied, unreturned, or former-employee credential remains a risk while it is still valid in the server, local controllers, or distributed databases. Engineering must convert this lifecycle into verifiable rules for request, approval, validity, revocation time, sources of truth, exceptions, offline operation, and evidence.

The lifecycle begins before credential issuance

A credential should not originate from an informal request to “grant access.” Before issuance, the organization must confirm identity, relationship, responsible sponsor or manager, required profile, expected duration, and termination conditions.

Identity, relationship, credential, and authorization should be modeled separately. The person identifies who the individual is; the relationship explains why the person has a relationship with the organization; the credential is the medium presented to the system; and authorization defines which doors, areas, schedules, and conditions may be used.

Physical credential lifecycle from request through revocation and audit

Issuance: correct identity, least privilege, and defined validity

Issuance should start from a formal event such as hiring, contracting, a recurring visit, project participation, site transfer, or temporary authorization. The system must record who originated the request and who had authority to approve it.

Least privilege also applies to physical access. A new user should receive only the permissions required for the planned work. Copying another employee’s profile without review can propagate legacy exceptions and temporary privileges.

Whenever the relationship has a known horizon, validity should be explicit. Contractors, recurring visitors, construction crews, consultants, auditors, and temporary workers should not depend on a future manual action to terminate access that already has a planned end date.

Physical and logical issuance must remain linked

A credential may be a card, mobile credential, biometric template, or a combination. The system must maintain an unambiguous relationship between the issued object and the authorized identity. MIFARE or DESFire environments also require coordinated key, application, and migration management. Mobile credentials add device, application, provisioning, and remote-revocation states. Biometrics add enrollment quality, template governance, and secure disposal.

Approval must not be embedded in technical operation

A classic risk appears when the same person requests, approves, and performs the grant. This concentrates authority and makes it difficult to distinguish a business decision from an administrative action.

A possible segregation of duties is:

Manager or sponsor requests and justifies.
Responsible function validates the relationship and prerequisites.
Approver authorizes the profile.
Responsible team performs issuance.
Audit reviews samples, exceptions, and critical permissions.

The exact number of actors may vary, but responsibilities must be explicit and compensating controls must exist where duties are combined.

Role, site, or project change: the Mover event

A large share of excessive access comes from privileges that were never removed. When a person changes role or site, the correct action is not simply to add a new profile. The process should recalculate the authorized final state.

Event	Minimum action	Expected evidence	Timeframe
Role change	Review groups and areas	New manager approval	According to criticality
Transfer	Remove old areas and add new ones	Before/after comparison	At transfer milestone
Leave	Suspend defined profiles	HR event + EACS log	According to risk
Temporary project	Time-bounded permission	Sponsor + end date	Automatic
Temporary elevation	Limited privilege	Justification and approval	Mandatory expiration

Expiration is a preventive control

Known-duration authorization should expire automatically. Expiration can exist at credential, relationship, group, temporary authorization, visitor profile, emergency credential, or operational-exception level.

Scheduled expiration differs from early revocation. Expiration occurs on a predefined date; revocation occurs because an event invalidated the privilege earlier, such as termination, a lost card, contract end, incident, fraud, or risk change.

Revocation: measure until the last decision point

Marking a credential as revoked at the central server does not prove that it stopped working in the field. The change must reach controllers, biometric terminals, caches, mobile applications, and every other component that can decide access.

The revocation SLA must therefore be end to end: from the triggering event until the last relevant decision point no longer accepts the credential. The process should define source event, transformation into a physical revocation, maximum tolerated delay, offline handling, propagation confirmation, and response to a controller that does not synchronize.

Lost, stolen, or unreturned credentials

Loss and theft require an easy reporting flow for the user and a rigorous revocation flow for the security team. A replacement should not be activated without invalidating the previous medium unless an explicitly controlled overlap policy exists.

Evidence should relate identity, previous credential, report time, revocation owner, propagation time, replacement credential, and any subsequent use attempt.

Biometrics require their own lifecycle

A biometric characteristic cannot be “replaced” like a card. The process must address template cancellation, re-enrollment, modality change, cryptographic protection, retention, distributed copies, backups, and deletion. Because biometrics are sensitive personal data, LGPD requirements for purpose, necessity, security, and governance are directly relevant.

Integration with HR and identity systems

Automating the lifecycle through HR, directory, or IAM can reduce manual work and shorten the interval between an organizational event and its physical effect. This depends on a clear architecture for sources of truth, attributes, transformation rules, APIs, webhooks or middleware, retries, idempotency, queues, logging, and reconciliation.

Logical and physical identities have related but not identical lifecycles. The sequence between corporate-account disablement and physical revocation should be deliberate and documented.

Profiles, groups, and attributes

Authorization may be governed through groups, roles, attributes, or a combination. Each profile should have a clear owner, purpose, included areas, schedules, eligibility rules, and review process. Critical groups require stricter governance.

Attribute-based rules can use site, role, contract, shift, and relationship status, but automation multiplies the effect of bad data. Governance therefore shifts toward rule design, data quality, and exception management rather than disappearing.

Temporary profiles and exceptions

Temporary access is unavoidable in maintenance, construction, contingency, inspection, and audit. Every exception should carry a reason, requester, approver, scope, start time, end time, restrictions, and closure evidence. Repeated renewals indicate that the permanent profile or underlying operational process may require redesign.

Offline operation and distributed databases

Resilient EACS architectures keep local data to operate without the central server. The design must define which data resides in each controller, maximum disconnection time, local expiration behavior, priority revocation propagation, divergence detection, and the policy that applies after the maximum unsynchronized interval is exceeded.

Logs: record transitions, not only passage events

Lifecycle audit requires administrative events such as request, approval, issuance, activation, profile change, credential association, suspension, expiration, revocation, replacement, exception, synchronization failure, and use attempts after revocation.

Retention must balance operational, contractual, security, privacy, and investigation needs. Keeping everything indefinitely increases exposure, while deleting too early weakens evidence.

Periodic recertification

Even with automation, privileges require periodic review. Priority should be given to critical permissions, exceptions, old privileges, inactive users, relationships approaching expiration, and differences from the expected profile.

Maturity metrics

Indicator	What it reveals	Warning sign
Issuance time	Onboarding efficiency	Improvised credentials
End-to-end revocation time	Exposure after termination/loss	Unsynchronized controllers
Expired but active	Policy failure	Orphan authorization
Exceptions without end date	Governance weakness	Permanent temporary access
Out-of-flow changes	Administrative bypass	Missing segregation
Use after revocation	Exposure or collection failure	Possible misuse
Profiles not recertified	Governance debt	Accumulated privileges

Averages must not hide critical exceptions. A single delayed revocation for a high-risk area may matter more than hundreds of normal transactions.

Migration between platforms

Replacing cards, readers, controllers, or software does not remove the obligation to preserve lifecycle governance. Migration should distinguish valid identities from historical records and avoid carrying obsolete credentials into the new platform.

The inventory should include identities, credentials, groups, exceptions, validity dates, biometric templates, keys, controllers, integrations, and logs that must be preserved. Migration is also an opportunity to eliminate authorization debt rather than copy it.

Cybersecurity of administration

The EACS administrative interface is privileged. Anyone able to issue, modify, or reactivate permissions can bypass physical controls without touching a door. Administrative accounts therefore require strong authentication, least privilege, segregation, individual attribution, logging, and periodic review. Service accounts used by integrations should have minimal scope.

Turning policy into design requirements

Requirements such as “allow registration and deletion” are insufficient. The design can specify defined states, start/end validity, suspension, monitorable revocation, multiple credentials per identity, replacement with history, versionable profiles, administrative audit trail, expiration of exceptions, reconciliation, offline operation, orphan reports, and authenticated APIs.

FAT, SAT, and commissioning

Testing must cover state transitions rather than only presenting a valid credential. Useful cases include:

Issue a credential with future validity.
Change a group and remove the old privilege.
Revoke at the server and measure time to the last controller.
Lose communication and verify the defined policy.
Restore communication and reconcile.
Attempt to use a revoked credential.
Replace a card and invalidate the previous one.
Terminate an external relationship.
Restore a backup without resurrecting revoked states.
Audit who performed each change.

Contracting engineering for credential lifecycle

With multiple sites, large populations, high turnover, contractors, integrations, or critical areas, lifecycle governance becomes an engineering problem rather than simple software configuration. A technical scope may include process and identity-source survey, Joiner–Mover–Leaver matrix, credential states, approval matrix, expiration and revocation rules, SLAs, integration architecture, logs, offline operation, exceptions, LGPD, test plan, migration, and as-built documentation.

When to review an existing process

Warning signs include active former employees, contractors without expiration, unexplained differences among sites, administrative changes without approval, lost cards that remain active, no attribution for grants, unmonitored integrations, backups that can reintroduce old states, and large volumes of permanent exceptions.

Credential-state matrix

A design becomes clearer when the lifecycle is expressed as a state machine. Terms such as active, blocked, and deleted can have different meanings across manufacturers, so the specification should declare the operational effect of each state.

State	Can authenticate?	Remains in history?	Can be reactivated?	Typical use
Pre-registered	No	Yes	Yes	User waiting for start date
Active	Yes	Yes	n/a	Current relationship
Suspended	No	Yes	Yes	Leave or investigation
Expired	No	Yes	According to policy	End of validity
Revoked	No	Yes	Usually through a new flow	Loss, termination, or incident
Replaced	No	Yes	Not for the same medium	Card/device replacement
Archived	No	Yes	Not directly	Historical retention

Suspension should preserve identity, history, and evidence. Definitive deletion should be a controlled retention action rather than an operational shortcut.

Governance of access profiles

Each profile should have a meaningful name and purpose, responsible owner, included areas and points, schedules and calendars, eligible population, criticality level, additional requirements, review date, and change history.

Generic profiles such as “GENERAL,” “TOTAL,” or “MASTER” deserve scrutiny. Profile review should also check accumulated expansion: a group that began with ten doors may contain fifty after years of incremental changes.

Backup, restore, and the risk of resurrecting access

A backup is an old authorization state. Restoring a database created before several terminations may reintroduce revoked credentials as active unless reconciliation is performed.

The recovery plan should define the authoritative source after restore, how post-backup events are reapplied, how controllers are reconciled, how critical revocations are prioritized, and which evidence proves the final state is correct.

Configuration change management

Changes to rules, firmware, software versions, integrations, and credential models can affect lifecycle behavior. Relevant changes should carry version, reason, expected impact, test plan, owner, and rollback capability, especially when expiration, local caching, synchronization, or APIs are affected.

Segregation among operator, administrator, and auditor

The operator issuing cards does not necessarily need global-rule privileges. The technical administrator does not need authority to approve access to a critical room. The auditor does not need to modify records. Administrative profiles should reflect these differences, and individual administrative authentication—preferably with MFA—should preserve attribution.

Responsibility matrix

Where HR, security, IT, managers, integrators, and contracted companies participate in the same lifecycle, a RACI matrix reduces gaps.

Activity	HR	Manager	Security	IT/IAM	Integrator
Create relationship	R	C	I	I	I
Request access	I	R	C	I	I
Approve critical area	I	A	C	I	I
Issue credential	I	I	R	C	C
Maintain integration	I	I	C	R	C
Revoke after termination	R	I	A/R	C	I
Test system	I	C	A	C	R
Audit trail	C	C	R	C	I

The exact allocation may differ; the objective is to prevent a critical event from belonging to nobody.

Failure scenarios that must be anticipated

HR or IAM unavailable

The EACS should continue applying the last valid state while the integration records the outage. Critical pending changes require a contingency mechanism.

Controller without communication

The controller should apply local rules compatible with area criticality. Maximum acceptable unsynchronized time must be defined.

Incorrect clock

Expiration and schedules depend on time. Clock drift can extend or prematurely end authorization. Time synchronization and related alarms are therefore infrastructure requirements.

Queue or middleware failure

Unprocessed events must remain visible and recoverable. A failed termination event cannot simply disappear.

Duplicate identity

The resolution process must preserve history and ensure that the duplicate identity does not remain active after records are merged.

Acceptance criteria by requirement

Requirement	Test method	Evidence
Automatic expiration	Credential with short validity	Denial event after deadline
Revocation	Cancel active user	Measurement to last controller
Suspension	Suspend relationship	Denial without history loss
Replacement	Issue new medium	Old denied, new authorized
Reconciliation	Create controlled divergence	Detection and correction
Offline	Isolate controller	Behavior according to matrix
Audit	Change profile	Log with user, date, and object
Restore	Recover test backup	Reconciled state and preserved revocations

This matrix turns the lifecycle into a contractible and auditable engineering object.

Assisted operation after delivery

The initial operating period reveals conditions FAT and SAT may not reproduce at scale: hiring peaks, shift changes, many terminations in one day, intermittent failures, misunderstood profiles, and recurring exceptions. Assisted operation should monitor indicators, tune alerts, validate propagation times, and close documentation issues before final handover.

Offboarding sequence across systems

Relationship termination rarely affects only the EACS. Corporate accounts, VPN, email, business systems, parking, and physical access may require different disablement times. The sequence should be documented rather than assumed to be simultaneous.

Planned terminations may use a common milestone. Sensitive terminations may require synchronized execution. Asset return and escorted procedures can also require a formally defined limited exception rather than leaving the complete profile active.

Privileged physical access

Permissions to data centers, electrical rooms, vaults, operation centers, security areas, and network infrastructure may require additional approval, shorter validity, MFA, two-person rules, more frequent review, and specific alerts. Recertification should therefore be risk-weighted rather than treating all doors equally.

Retention and disposal of records

The lifecycle also ends for data. Identity history, passage events, administrative logs, images, biometric templates, and request documents may have different purposes and retention periods. The design should define what remains for audit, what is anonymized or deleted, and how disposal is evidenced where applicable.

Final considerations

Credential lifecycle governance keeps identity, relationship, and authorization coherent over time. Correct issuance is only the first step. Security depends on changing, expiring, suspending, and revoking privileges at the appropriate moment, including in local controllers and integrated systems.

Mature designs treat every transition as a verifiable requirement and define sources of truth, responsibilities, SLAs, logs, exceptions, and tests. This makes it possible to demonstrate who had access, why, during what period, and who approved each change.

Referências técnicas

[1] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 60839-11-1:2013 — Alarm and electronic security systems — Part 11-1: Electronic access control systems — System and components requirements. 2013. Disponível em: https://webstore.iec.ch/en/publication/3662

[2] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NIST SP 800-116 Rev. 1 — Guidelines for the Use of PIV Credentials in Facility Access. 2018. Disponível em: https://csrc.nist.gov/pubs/sp/800/116/r1/final

[3] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NIST SP 800-53 Rev. 5 — Security and Privacy Controls for Information Systems and Organizations. Disponível em: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final

[4] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Electronic Physical Access Control Systems (ePACS) Security Control Overlay for NIST SP 800-53 Rev. 5. 2021.

[5] BRASIL. Lei nº 13.709/2018 — Lei Geral de Proteção de Dados Pessoais. Disponível em: https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm

Perguntas frequentes

What is the difference between expiration and revocation?

Expiration occurs on the planned date; revocation cancels an authorization earlier because of termination, loss, contract end, an incident, or another change in condition.

Does revoking a credential on the server mean it has stopped working at every door?

Not necessarily. In distributed systems, the change must reach local controllers and terminals. The SLA should include the last relevant decision point.

Should third-party credentials have automatic expiration?

Yes when the end of the relationship is known. Automatic expiration reduces orphan authorization and dependence on manual cancellation.

What should be audited besides entry and exit events?

Creation, approval, issuance, profile changes, suspension, expiration, revocation, replacement, exceptions, and synchronization failures.

How should this lifecycle be tested during commissioning?

By testing state transitions, including offline behavior, restoration, propagation, revocation, and audit evidence.

Materiais técnicos complementares