{"id":74963,"date":"2026-09-12T09:30:49","date_gmt":"2026-09-12T12:30:49","guid":{"rendered":"https:\/\/a3aengenharia.com\/?post_type=articles&p=74963"},"modified":"2026-09-14T19:42:32","modified_gmt":"2026-09-14T22:42:32","slug":"hr-active-directory-iam-physical-identity-integration","status":"publish","type":"articles","link":"https:\/\/a3aengenharia.com\/en-us\/content\/technical-articles\/hr-active-directory-iam-physical-identity-integration\/","title":{"rendered":"Integration Between Access Control, HR, Active Directory, and IAM: Architecture, Identity Lifecycle, and Design Criteria"},"content":{"rendered":"\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Architecture and responsibilities<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Source of truth by attribute<\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

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

Persistent identifier<\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Bidirectional architecture does not mean bidirectional authority<\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Joiner, mover, and leaver lifecycle<\/h2>\n\n\n\n

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

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.<\/p>\n\n\n\n

Mover must recalculate, not only add<\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Leaver must reach the physical point<\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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

Sequencing logical and physical access<\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Joiner\u2013Mover\u2013Leaver flow between HR, identity governance, and physical access control<\/title>