PSIA Physical Logical Access Interoperability

PLAI exchanges identity and access information between systems. Track the source identity, destination permissions and enforcement state when checking synchronisation and revocation.

Sources and scopeSource record 25 August 2026

Technical source record: 25 August 2026. Check the linked documentation for current product requirements.

Published PSIA overview and v3.1 baseline were reviewed; the current Integrators Kit, schemas, conformance tools, and product specific adapters are required for implementation.

Verification and testing

On this page

Overview#

Physical Logical Access Interoperability (PLAI) normalises and synchronizes identity, credential, role, and access information between an authoritative logical/HR source and disparate physical access control systems (PACS). PSIA describes PLAI as using the LDAP v3 interface and lists Area Control including PLAI v3.1, released 7 August 2019, in its current downloads.¹²

authoritative HR/IAM/directory
            │ lifecycle and roles
            ▼
       PLAI agent/model
       ┌────┴─────────┐
       ▼              ▼
 PACS adapter A   PACS adapter B   ... biometric/visitor integrations

The architecture must name one authority for each attribute and decision. “Single source” can't remain a slogan: record whether HR owns legal identity/employment, IAM owns role, a PACS owns card format/number, a local site owns access level, and a biometric system owns templates.

Synchronization contract#

For every entity and field define stable identifier, source, schema/version, normalisation, create/update/disable/delete semantics, effective/expiry time, precedence, conflict handling, retry, idempotency, tombstone retention, acknowledgement, reconciliation interval, and audit. Don't use name or email as the immutable person key.

High impact cases require explicit state machines:

pre hire and future dated activation;
transfer between sites/roles and overlapping entitlements;
termination/emergency revocation when one PACS is offline;
lost/replaced/shared credentials and duplicate credential detection;
leave/suspension and time bounded visitor/contractor access;
rename, rehire, merger of duplicate identities, and deletion/privacy requests;
adapter backlog, partial fan out, poison record, retry exhaustion, and later reconciliation.

Never represent “could not update PACS B” as global success. Return a per target result and expose age/backlog. Revocation workflows should fail closed for new grants, use an approved emergency path, and alert until every target is reconciled.

Security and privacy#

Authenticate every agent, adapter, directory, and PACS with unique service identity; encrypt transport and validate peer identity. Authorise minimum LDAP base/attributes and minimum PACS operations. Separate provisioning, reconciliation/read, revocation, and administration roles. Protect queues, exports, backups, logs, schema maps, and dead letter records as sensitive identity data.

Biometric templates and location/presence data need purpose limitation, data minimisation, jurisdictional retention/consent controls, and vendor specific protection. Avoid moving raw biometrics when a scoped reference or protected template meets the purpose. Don't use physical presence as silent authentication for unrelated logical access without policy, user notice, freshness, anti tailgating limitations, and an independent recovery path.

Conformance evidence#

PSIA provides an Integrators Kit and test tool packet. Its product page explicitly says PSIA doesn't conduct conformance testing; vendors run the test and submit self declarations/results.³ Verify the exact vendor product, version, PLAI version, declaration date, tested group/event set, known exceptions, and your own cross vendor lifecycle cases.

Validate directory, PLAI agent, PACS adapter, conformance, reconciliation, and identity lifecycle behaviour with synthetic identities in an isolated authorised environment.

Primary sources#

Section overview · Wiki home