HR, Active Directory and IAM Integration with Physical Access Control

Integration between physical access control, HR, Active Directory, and IAM: sources of truth, Joiner-Mover-Leaver, APIs, security, testing, and acceptance.

Check it out!

This article presents a governance architecture for synchronizing corporate information with physical permissions in a traceable way. The objective is to transform organizational events into verifiable states, with clearly defined responsibilities, rules, evidence, and acceptance criteria.

The approach must distinguish the authority of each system, prevent duplicates, handle relationship changes, and keep operations predictable when any component is unavailable. It must also support audit and reconciliation between the expected state and the state actually applied in the field.

Architecture and responsibilities

The first design decision is to separate person, relationship, logical account, and physical authorization. These objects are related but are not equivalent. The same person may have more than one relationship over time, more than one corporate account, and different physical credentials. If all of these elements are treated as a single record, organizational changes can create duplicates or preserve obsolete privileges.

HR normally owns the employment relationship, business unit, manager, role, and relevant dates. The corporate directory owns logical accounts and groups. An identity-governance platform may coordinate roles, approvals, and joiner, mover, and leaver cycles. The electronic access control system remains responsible for physical credentials, zones, schedules, controllers, and passage events.

Source of truth by attribute

The architecture must state which system is authoritative for each attribute and who may correct it. Relationship status may come from HR; a corporate identifier may be maintained by an identity service; physical groups and zones belong to the EACS. If two systems write the same field without a precedence rule, synchronization may alternate states or overwrite a valid decision.

Data	Preferred source	Use in the process	Risk if inconsistent
Person identifier	HR or IAM	Correlation across systems	Duplicate identity
Relationship status	HR	Activation and termination	Terminated person still active
Role or unit	HR	Role calculation	Inappropriate profile
Logical group	Directory/IAM	Corporate identity	Incorrect interpretation
Zones and schedules	EACS	Physical authorization	Excessive access
Credential	EACS	Physical authentication	Loss of traceability

Persistent identifier

Name, email, login, and UPN may change. They should not be the only correlation key. The design should use a persistent and unambiguous identifier that survives a name change, transfer, domain change, or rehire. When platforms use their own identifiers, the integration layer must maintain the relationship among them.

This also preserves history. A rehired person may return under a new relationship without becoming a new physical identity, while old privileges must not be automatically restored. The model should reuse the historical identity while recalculating authorization from the new relationship.

Bidirectional architecture does not mean bidirectional authority

Systems often exchange information in both directions: one system sends attributes and the EACS returns status, local identifiers, or events. This does not mean both systems may decide the same data. Communication direction and data authority are separate decisions.

The design must document inputs, outputs, frequency, triggers, validations, and divergence handling. This interface matrix is as important as the logical diagram because it allows operations and oversight teams to understand each platform’s responsibility.

Joiner, mover, and leaver lifecycle

The Joiner–Mover–Leaver model organizes the three events that most affect authorization. The Joiner creates the relationship and initiates provisioning; the Mover recalculates privileges when conditions change; the Leaver terminates what is no longer required. Automation should translate each event into an expected state rather than merely execute isolated add or delete operations.

For a Joiner, the process must know the start date, manager, role, unit, relationship type, and any approvals. Pre-provisioning may be useful as long as the physical authorization only becomes valid at the intended milestone. This avoids first-day queues without granting the privilege too early.

Mover must recalculate, not only add

The Mover event is one of the main sources of privilege accumulation. When someone changes role or unit, adding a new group without removing the previous one produces broader authorization than necessary. The correct rule is to compare the current state with the expected state after the change and produce coherent additions and removals.

Temporary transfers, projects, leaves, and substitutions also need to be modeled. An additional role for thirty days should have its own validity. If the condition becomes permanent, the change should pass through the appropriate flow instead of indefinitely renewing an exception.

Leaver must reach the physical point

Disabling a source record does not prove that physical access has stopped working. Termination must propagate through the chain to the EACS and, in distributed architectures, to the controllers that maintain local copies. Revocation time must be measured end to end and aligned with the site’s criticality.

The credential lifecycle article expands on issuance, change, expiration, and revocation. In this integration, the key point is to ensure that a corporate event produces the correct transition in the physical environment.

Event	Input	Expected state	Evidence
Hire	Approved relationship	Basic profile at start milestone	Approval + activation
Role change	New role	Remove old and apply new	Before/after comparison
Transfer	New unit	Recalculated zones	Authorization matrix
Leave	Temporary status	Suspension according to policy	Event and log
Termination	End of relationship	Effective revocation	End-to-end timestamps

Sequencing logical and physical access

A corporate account and a physical credential may have different milestones, especially in planned terminations, asset-return processes, or escorted procedures. This sequence must be deliberate and documented. The error is to let the order become an accidental consequence of each system’s processing time.

For sensitive situations, the organization may require coordination across several systems within a common window. The procedure should identify owners, maximum time, exceptions, and how the final state will be proven.

Joiner–Mover–Leaver flow between HR, identity governance, and physical access control

Data, roles, and authorizations

Active Directory, IAM, and EACS should not be treated as three names for the same problem. The corporate directory maintains objects, accounts, and logical groups; the identity-management layer organizes roles, approvals, and lifecycle; the EACS applies physical authorization through credentials, zones, schedules, and local rules.

A direct mapping such as “directory group = door” may seem efficient, but it is reliable only if that group was created and governed for that purpose. Technical or historical groups may contain members for reasons unrelated to physical security. The integration must make the transformation rule explicit.

Roles and attributes can work together

In a role-based model, organizational function determines a set of permissions. In an attribute-based model, unit, role, shift, relationship type, and other fields participate in the decision. A hybrid architecture is often practical: eligible attributes determine physical roles, while roles maintain zones and schedules that managers and operations can understand.

Automation reduces manual maintenance, but it can also amplify bad data. An incorrect unit code or a free-text attribute written in inconsistent ways can affect many people. Values that feed rules should therefore be normalized, versioned, and validated.

Data quality is an engineering requirement

The design should specify mandatory fields, allowed values, null handling, rules for inconsistent dates, and duplicate detection. Inconsistent records should not be silently adapted by the integration, because that transfers the source error into physical authorization.

When a record does not meet the criteria, a safer approach is to keep it in a pending state and generate evidence for correction at the source. This preserves data authority and facilitates audit.

Directories and provisioning standards

LDAP is used to access directory services. SCIM was standardized for cross-domain identity management. APIs and webhooks can transport events and data that are specific to the physical system. None of these technologies replaces governance; they only implement part of the communication.

For deeper treatment of integration mechanisms, the article on APIs, webhooks, and middleware in access control discusses architecture, queues, events, and responsibilities. Here, the focus remains on the corporate lifecycle and its effect on physical authorization.

Transformation matrix

The rule that converts corporate attributes into authorization should exist as a design artifact. It may relate role, unit, relationship type, and shift to a physical role and record additional approvals for critical areas.

Corporate condition	Physical role	Zone	Schedule	Additional approval
Administrative / Headquarters	Basic corporate	Administrative areas	Business hours	No
Maintenance / Plant A	Local maintenance	Planned technical areas	Shift	According to criticality
Temporary project	Project-specific	Project zones	Defined window	Sponsoring manager
Critical area	Privileged	Restricted zone	Restricted	Area owner

The matrix must be readable by people who do not develop the integration. If the business rule exists only in code, review, procurement, and acceptance become dependent on the supplier.

Integration architecture: source, transformation, transport, and destination

An integration is easier to understand when decomposed into four responsibilities: the source produces the event or data; transformation converts attributes and applies rules; transport delivers the information; and the destination materializes the new state. This separation helps locate failures and avoids placing all logic inside an opaque connector.

The source must provide data with known meaning and quality. Transformation should record which values were received and how they were converted. Transport must provide sufficient processing confirmation for operations. The destination must allow verification of the state actually applied.

Real-time, events, and batches

Not every item needs to travel in real time. Planned hires can be provisioned in advance with a future date; sensitive terminations may require rapid propagation; recertification can run in batch. Each event should be classified by the maximum acceptable delay.

Event-driven processing reduces latency but requires monitoring of queues and reprocessing. Periodic batches are simpler but create known divergence windows. A hybrid architecture can use events for critical changes and periodic reconciliation to ensure consistency.

Idempotency and out-of-order events

The same event may be delivered more than once. Processing must recognize the repetition and reach the same state without duplicating a person, relationship, or credential. This idempotency principle is especially important when delivery uses automatic retry.

Events can also arrive out of order. A delayed role change must not reactivate privileges after a more recent termination. Record version, sequence, timestamp, and current state help prevent regression.

Invalid records and quarantine

When an event arrives incomplete or contradictory, the integration needs a known intermediate state. Instead of silently discarding it or filling values for convenience, the record can be quarantined and linked to an operational issue.

Operations should be able to see the reason, source system, time, reprocessing attempt, and person responsible for correction. This turns an integration error into a treatable and auditable item.

Capacity and change peaks

Sizing must consider more than the daily average. Mass hiring, reorganizations, unit transfers, and collective terminations can generate high volume in a few minutes. The chain must process the peak within the required time without leaving critical changes behind less important events.

Connector limits, pagination, queues, licensing, and processing capacity should be verified before deployment. A system that works with ten test users may behave differently with thousands of changes.

Continuity and reconciliation

An integration cannot assume permanent availability of HR, directory, IAM, middleware, or the central server. The physical-control layer must continue operating predictably during outages, using local rules compatible with the risk of the installation.

The design should define how long each component may operate on previously synchronized data, which changes may wait, which events require a contingency procedure, and how operations will be reconciled when communication returns.

Local controllers and acceptable staleness

Controllers frequently cache credentials and rules to maintain availability. This is desirable but creates multiple copies of the authorization state. A change at the central server becomes effective only after it reaches the points that actually decide passage.

Area criticality should guide tolerance. An administrative door may accept a longer period with the last known state; a critical area may require an immediate alert, local procedure, or more restrictive policy when synchronization exceeds a defined time.

Reconciliation compares expected and effective states

Synchronizing events does not eliminate divergence. Temporary failures, manual changes, duplicate records, and out-of-flow modifications can produce different states between the source and the EACS. Periodic reconciliation should compare what should exist with what is actually configured.

Differences need classification. Some are errors that can be corrected automatically; others are authorized exceptions that should remain recorded; others require human decision. The important point is that divergence must not remain invisible.

Indicator	What it reveals	Expected action
Pending events	Processing delay	Investigate cause and age
User without source	Orphan identity	Validate relationship or terminate
Role mismatch	Divergent state	Recalculate or justify
Controller out of sync	Potentially incomplete revocation	Trigger contingency
Expired exception	Accumulated temporary privilege	Revoke and review process

Backup and recovery also affect time

Restoring an old database may reintroduce users or groups that had already changed. The recovery plan should therefore include reconciliation against current sources before the service is declared normalized.

Recovery testing should prove more than software startup. It must verify that the final authorization state matches the expected state and that events after the backup were reapplied or reconciled.

Time synchronization and evidence

When HR, IAM, integration, EACS, and controllers record different times, reconstructing a sequence becomes difficult. The architecture should maintain an appropriate time reference and consistent timestamps, including timezone where applicable.

This consistency is essential for SLA measurement and incident investigation. The process must distinguish when the event originated, when it was processed, and when it became effective at the physical point.

Testing and acceptance

Acceptance must prove process behavior, not merely show a synchronized screen. Tests should begin in a controlled environment, cover normal and abnormal events, and end with verification on the actual hardware.

FAT: validate rules and interfaces

During FAT, verify joiner, mover, and leaver rules, mappings, duplicates, invalid-record handling, reprocessing, manual changes, and reconciliation. It is also useful to simulate volumes above normal routine to observe queues and processing times.

Test cases should originate from requirements. If the organization requires a termination to become effective within a defined time, the test must record timestamps along the chain and demonstrate the result.

SAT: prove the effect in the installation

During SAT, the identity should pass through the intended process and produce the correct behavior at the actual door, turnstile, or barrier. A newly admitted user should open only authorized points; a role change should remove the old profile; a termination should result in denial.

Offline operation must also be tested. Isolate part of the communication, observe local behavior, restore connectivity, and verify reconciliation. The article on commissioning access-control systems in accordance with IEC 60839 expands the methodology for tests and evidence.

Traceability matrix

Requirement	Component	Test	Evidence
Entry at planned milestone	HR→IAM→EACS	Joiner	Activation at the correct time
Remove old privilege	Role rule	Mover	Before/after comparison
Revoke within required time	Complete chain	Leaver	End-to-end timestamps
Operate without directory	EACS/controller	Outage	Proven local policy
Detect divergence	Reconciliation	Controlled change	Alert and correction

Closure criterion

An approved test must have a result, evidence, and responsible party. Open issues should enter a controlled list with severity, deadline, and retest. The system should only be considered accepted once critical requirements are proven in production or in a previously agreed representative condition.

Contracting and operation

A suitable procurement scope must describe the process being delivered, not merely request “Active Directory integration.” The scope should state systems involved, sources of truth, organizational events, authorization rules, responsibilities, contingency operation, documentation, and acceptance criteria.

Useful deliverables include a logical architecture, source-of-truth matrix, Joiner–Mover–Leaver model, data dictionary, attribute-to-role transformation matrix, interface specification, exception flows, reconciliation criteria, test plan, RACI matrix, and as-built documentation.

Scope and responsibilities

The contract should state who provides data, who configures rules, who approves roles, who handles rejected records, who monitors divergence, who maintains documentation, and who accepts each stage. Poorly defined interfaces create gaps because each supplier may assume a responsibility belongs to another party.

Development, configuration, infrastructure, testing, and assisted operation should also be separated. A technically complete integration may remain operationally immature if the internal team has not received runbooks, matrices, contacts, and diagnostic procedures.

Measurement and acceptance criteria

Contract milestones may be tied to approved requirements, validated architecture, integration in homologation, completed FAT, completed SAT, delivered documentation, and completion of assisted operation. This reduces the risk of measuring only software installation without proving process behavior.

Acceptance criteria should define sample, mandatory cases, evidence, tolerances, and treatment of nonconformities. Relevant implementation changes must enter change management so documentation and tests remain consistent.

Assisted operation and handover

In the first real cycles, insufficient data quality, misunderstood groups, recurring exceptions, or processing times that differ from the laboratory are common. Assisted operation should monitor indicators, tune alerts, and close issues before final handover.

Handover should include diagrams, data dictionary, role matrices, error catalog, reconciliation procedures, test cases, and responsible parties. Without these artifacts, the organization may remain dependent on the integrator to interpret a solution that should already be under the owner’s governance.

Recertification and evolution

Even with automation, permissions must be recertified. Critical areas, privileged roles, and external populations may require more frequent review. Recertification helps identify old exceptions and changes that occurred outside the expected flow.

The process must also follow changes in corporate systems. New fields, reorganizations, interface versions, and policy changes should undergo impact analysis and regression testing. Governance continues after go-live.

Operational indicators

Provisioning time, revocation time, percentage of automated events, pending records, identities without a source, role divergences, manual exceptions, and mean reconciliation time help show where the process is no longer keeping pace with the organization.

The objective is not to create a bureaucratic dashboard. Indicators should reveal risk and guide action: for example, a small number of pending terminations may be more critical than thousands of successfully processed additions.

Specification, implementation, and acceptance checklist

Before procurement or production release, it is useful to confirm that critical decisions are actually documented. The checklist does not replace the design, but it helps identify gaps that often emerge only during commissioning or operation.

Sources of truth defined for identity, relationship, and attributes.
Persistent identifier defined across systems.
Joiner, Mover, and Leaver events documented.
Transformation rules among attributes, roles, zones, and schedules.
Additional approvals defined for critical areas.
Handling defined for third parties and exceptions.
Maximum propagation time defined by event type.
Behavior during outages documented.
Reconciliation process and divergence handling defined.
Administrative and operational logs sufficient for audit.
FAT and SAT case matrix prepared.
Objective acceptance and retest criteria defined.
As-built documentation and handover procedures planned.
Operational indicators and recertification defined.

The checklist also supports oversight. Each item should point to an artifact, requirement, or test, avoiding generic answers such as “the system supports it.” Acceptance must demonstrate the configuration actually delivered.

When specialized support becomes necessary

Complexity increases with multiple sites, different populations, critical areas, high turnover, legacy integrations, accumulated manual rules, or platform migration. In these scenarios, the integration is no longer an isolated configuration and requires requirements engineering, architecture, interface review, and commissioning.

Specialized support is also useful when data authority is unclear, termination propagation is delayed, exceptions are growing, or the organization cannot prove why a given person has a particular authorization. These signs point to a governance problem, not merely a software problem.

What to require from the final deliverable

At the end, the organization should receive a set of artifacts that allows it to operate and evolve the integration: updated diagrams, source matrix, data dictionary, transformation rules, profiles and zones, exception flows, reconciliation procedures, FAT/SAT results, closed-issue list, relevant parameters, and responsibilities.

This set reduces dependence on tacit knowledge and creates a foundation for audit, maintenance, expansion, and future migrations.

Final considerations

A mature corporate integration must produce predictable, traceable, and testable authorization states. Its value lies in process governance, not merely in data exchange among platforms.

Referências técnicas

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

[2] IETF. RFC 4511 — Lightweight Directory Access Protocol (LDAP): The Protocol. Disponível em: https://www.rfc-editor.org/rfc/rfc4511

[3] IETF. RFC 7644 — System for Cross-domain Identity Management: Protocol. Disponível em: https://www.rfc-editor.org/info/rfc7644/

[4] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. 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

[5] MICROSOFT. Lifecycle Workflows — Joiner, Mover, Leaver. Disponível em: https://learn.microsoft.com/en-us/entra/id-governance/understanding-lifecycle-workflows

[6] 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

Should Active Directory be the source of truth for physical access?

Not necessarily. The directory maintains identities and logical groups; organizational relationship and attributes may come from HR, while the EACS applies physical authorization.

Does SCIM replace LDAP?

No. LDAP is a protocol for access to directory services; SCIM was standardized for cross-domain identity management. They perform different functions and may coexist.

Should an HR termination block the physical point immediately?

The required time should be defined according to risk. What matters is measuring the time between the termination event and effective revocation at the relevant physical points.

How should third parties without an Active Directory account be handled?

The architecture should maintain a dedicated source for external identities, with sponsor, company, relationship, validity, and permission rules, integrating it with the EACS directly or through a governance layer.

How should integration between corporate identity and physical access be tested?

With joiner, mover, and leaver scenarios, invalid records, outages, restoration of communication, reconciliation, and verification of the result on actual hardware.

Materiais técnicos complementares