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.
\nThe 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.
\nThat 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.
\nThe 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.
\nThe following steps are DSE recommendations based on the cited source.
\nBuild 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.
\nTest 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.
\nRepeat the final test from a second authorized administrative client to expose hidden local caching or client-specific state before declaring the interface portable.
\nRetain 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.
\n