Prove Profile A credential and schedule administration end to end

Bottom line: Profile A defines a useful interoperability boundary, not a promise that two products implement every administrative workflow identically. Acceptance should prove that an authorized change becomes the intended door decision and can be reversed and audited.

Source fact: Profile A covers selected access-control configuration

The official ONVIF Profile A page describes profile functions for access-control configuration. Its overview includes credentials, schedules, access rules, and events, with features identified as mandatory or conditional for conformant devices and clients.

That feature model matters when evaluating a client-device pair. A function can be conditional, a client can expose only part of the model, or a product can be conformant while a local workflow depends on an extension outside Profile A.

Source boundary and applicability

The ONVIF page describes the profile and conformance concepts; it does not certify an unnamed product, prove two releases interoperate, or validate cybersecurity, database migration, door hardware, life safety, or identity governance. Check the official ONVIF conformant-products database and each vendor’s exact model, version, and supported feature statement. Profile A is not a substitute for Profile C or other interfaces where different functions are needed.

Applicability questions

• Are both the client and device officially conformant for the exact product and version?
• Which required fields and functions are mandatory, conditional, or vendor-specific?
• How are person identity, credential token, schedule, access rule, door, and event identifiers mapped?
• What happens to existing assignments when a credential or schedule is updated or deleted?
• Are administrative operations authenticated, authorized, encrypted, logged, and recoverable?

DSE recommendation: test the complete reversible lifecycle

The following steps are DSE recommendations based on the cited source.

Build a requirements-to-profile matrix and mark each necessary operation as mandatory, conditional, or outside the profile. In a test tenant or approved maintenance window, create a test credential, assign a narrow rule and schedule, confirm entry only at the intended door and time, change the schedule, revoke the credential, and delete the test objects. Observe both client and device state after each step.

Test duplicate identifiers, invalid values, clock differences, partial communication failure, controller offline operation, and resynchronization. Protect production doors with rollback, life-safety coordination, and a known mechanical or operational recovery path.

Repeat the final test from a second authorized administrative client to expose hidden local caching or client-specific state before declaring the interface portable.

Verification and evidence

Retain official conformance records, version inventory, feature matrix, sanitized API or application logs, before-and-after object exports, access events, offline and recovery results, negative tests, rollback evidence, and acceptance signatures. Record every vendor extension needed so future replacement does not assume it is portable.

Official references

• ONVIF Profile A – ONVIF