ONVIF in access control: differences between Profiles A, C and D, interoperability, official conformance, device/client roles, and FAT/SAT testing.
Check it out!
ONVIF in access control is the use of ONVIF standardized interfaces to enable interoperability between devices and clients in IP-based electronic access control systems. In this domain, the core profiles are ONVIF Profile A, focused on configuring credentials, schedules and access rules; ONVIF Profile C, focused on door control and event management; and ONVIF Profile D, focused on peripherals such as readers, locks, sensors, keypads and biometric devices.
This scope differs from the better-known use of ONVIF in video surveillance. The term ONVIF is widely associated with cameras and VMS platforms, but Profiles A, C and D specifically address the physical access ecosystem. In design, the ONVIF logo or a generic statement that a product “supports ONVIF” is not enough: it is necessary to verify which profile, the product’s role as device or client, which functions are mandatory or conditional, which firmware/software version appears in the official conformance database, and whether the set of functions required by the design is actually covered.
ONVIF is not a single protocol or a generic guarantee of compatibility
ONVIF is a standardization initiative for interfaces used by IP-based physical security products. Functionalities are organized into specifications and profiles. Each profile brings together a fixed set of capabilities that conformant devices and clients must implement at the levels defined by ONVIF.
This means that the question “does the equipment have ONVIF?” is incomplete. Two products may be ONVIF conformant and still support different profiles intended for different functions. A Profile D reader and Profile A software, for example, are not automatically equivalent and do not perform the same role in the system.
The general article What is ONVIF? should remain the reference for the broader concept. Here, the focus is the specific application to physical access control and the functional differences among Profiles A, C and D.
Profiles A, C and D cover different layers of access control
ONVIF must be specified by function: profile, device/client role, features and conformant version. “ONVIF compatible” alone does not define interoperability.
ONVIF describes the three profiles as complementary:
| Profile | Main focus | Examples of functions |
| Profile A | access control configuration | credentials, schedules, rules and privileges |
| Profile C | door control and events | site, doors, access points, events and alarms |
| Profile D | access control peripherals | readers, biometrics, keypads, sensors, locks and displays |
This separation matters because interoperability must be specified by function. A design that requires only “ONVIF” without stating the profile and expected function leaves room for products that are formally ONVIF compatible in another area but unsuitable for the contracted access integration.
ONVIF Profile A is focused on access configuration
ONVIF Profile A was defined for configuration functions in electronic access control systems. According to ONVIF, it covers granting and revoking credentials, creating schedules, and assigning access rules.
A Profile A conformant device can provide information, status and events, and allow configuration of entities such as rules, credentials and schedules. A Profile A client can provide these configurations and receive standardized access-related events.
From an engineering perspective, this places the profile close to functions typically associated with the physical identity management layer: who holds which credential, during which time windows, and under which privileges. This does not mean Profile A replaces corporate integrations with HR or IAM; it means that it standardizes specific interfaces within the ONVIF domain.
Profile A is particularly relevant to multivendor systems
In environments where management software and access devices come from different manufacturers, a standardized interface reduces dependence on proprietary drivers for functions covered by the profile.
The engineering benefit lies in the ability to specify interoperability outcomes rather than a single combination of brands. However, the actual set of mandatory and conditional features must be checked. A requirement that depends on a function outside the profile may still require a specific API, SDK or integration.
Therefore, “Profile A conformant” should be treated as evidence that a standardized set of functions is covered, not as a promise that every advanced function of every platform will be interchangeable.
ONVIF Profile C addresses doors, access points and events
ONVIF Profile C targets electronic access control system products and covers site information, door control, and event and alarm management.
In practice, it is the profile most directly related to the operational behavior of doors and access points. It can be used in scenarios where a client needs to know door status, control basic functions, and receive standardized events.
This is especially relevant in integration with security platforms. Instead of each manufacturer representing doors, access and alarms through a completely proprietary interface, Profile C establishes common services and vocabulary for the functions defined in its specification.
Profile C should not be confused with other vendors’ “Profile C” labels or commercial naming
The letter C is part of ONVIF’s profile system. It does not represent a “Class C” security level or a door performance category. The design should explicitly cite ONVIF Profile C and, when needed, the required profile functions.
It is also not enough to find the term Profile C in marketing material. Official conformance must be verified in the ONVIF conformant products database for the corresponding model and firmware/software version.
ONVIF Profile D extends standardization to peripherals
ONVIF Profile D was created for access control peripheral interfaces. ONVIF includes token and card readers, mobile credentials, biometric readers, cameras used for recognition, keypads, sensors, locks, displays and LEDs in this universe.
The architecture matters: a Profile D device captures an identifier or access request and sends it to a client located in a secure layer, such as a control unit or management software. The client maintains rules, schedules and credentials, makes the decision, and can return an action to the peripheral.
This separation helps keep the access decision in an appropriate component or application rather than assuming every edge peripheral stores the complete access policy.
Profile D does not turn every reader into a standalone controller
The Profile D specification itself distinguishes the peripheral from an access control unit. A Profile D device does not need to store rules, schedules or all credentials locally; it can forward identifiers to the client responsible for making the decision.
This matters in design because “ONVIF IP reader” may refer to different architectures. The engineer needs to define where the decision is made, what happens when communication with the client is lost, which local functions exist, and how the door behaves under contingency conditions.
The profile standardizes the intended interface; it does not eliminate the need for functional architecture and availability analysis.
A, C and D are complementary, not successive versions of the same feature
It is incorrect to interpret Profile D as “newer and better” than Profile C, or Profile A as a full replacement for C. The three have different objectives and can coexist within the same system.
A solution may use Profile A for policy configuration, Profile C for doors and events, and Profile D for peripherals. The required combination depends on each product’s role and the flows defined in the design.
ONVIF also indicates that access control systems may use other profiles, such as Profile M in certain metadata and event scenarios. This does not change the focus of this article: A, C and D form the core set directly oriented to configuration, door control and access peripherals.
Device and client must support the same profile for the corresponding function
ONVIF interoperability assumes compatible roles. A device exposes services; a client consumes those services. For a standardized function to operate, both must be conformant with the relevant profile and implement the applicable requirements.
This prevents a common but incorrect assumption: “the hardware is ONVIF, so any ONVIF software will work.” Compatibility depends on the profile and function. A Profile T video client does not replace a Profile C client for door control merely because both belong to the ONVIF ecosystem.
In the integration matrix, the design should identify at least:
- the product or function acting as device;
- the product or function acting as client;
- the required ONVIF profile;
- features required by the use case;
- functions outside the profile that will depend on additional integration;
- validated firmware/software version.
“Supports ONVIF” is not the same as being ONVIF conformant
ONVIF maintains an official Conformant Products database and states that this is the authoritative source for verifying conformance. A product is considered officially conformant only when it passes the defined process and is registered with the corresponding profile.
In addition, conformance is tied to the specific firmware/software version registered. Checking only the model and manufacturer is not sufficient when the installed version differs from the listed one.
This verification should be part of submittal review, equivalency analysis, FAT or commissioning whenever ONVIF conformance is a contractual requirement.
The official database should be part of equivalency analysis
If the tender, specification or design requires Profile A, C or D, the supplier should demonstrate that the offered model and applicable version appear in the official database for the requested profile.
The manufacturer’s mere status as an ONVIF member does not prove conformance for all products. ONVIF itself warns that membership and marketing claims do not replace the product’s official listing.
A conformance matrix can record manufacturer, model, firmware/software, profile, device/client role, URL of the official listing, relevant conditional features, and test observations.
Profiles define a baseline of interoperability, not the entire solution
Access systems include functions that may fall outside a profile’s scope: specific biometric capabilities, visitor workflows, advanced IAM policies, dashboards, analytics, proprietary automations, or ERP integrations.
The design should separate three layers:
- functions covered by the required ONVIF profile;
- functions standardized by another interface or standard;
- functions that depend on a proprietary API/SDK.
This separation reduces the risk of promising interoperability that the profile does not cover and helps identify future vendor lock-in points.
ONVIF can reduce dependence on proprietary integrations, but it does not eliminate vendor lock-in by itself
A standardized profile improves portability in the layer it covers. However, the complete system may still depend on databases, licensing, workflows, management functions, credential formats and manufacturer-specific extensions.
Therefore, ONVIF should be used as an architecture criterion, not as a slogan for technology independence. The design needs to map which interfaces are standardized and which remain proprietary.
In future migrations, this documentation helps assess which components can be preserved and which integrations will need to be rebuilt.
OSDP and ONVIF operate at different layers
OSDP is a protocol widely used for communication between readers and controllers over a field link. ONVIF operates with IP interfaces between devices and clients for standardized physical security functions.
Therefore, a design may use OSDP Secure Channel between a reader and controller and ONVIF at another layer between a controller, IP peripheral or management software. They are not direct competitors.
This distinction avoids specifications such as “OSDP or ONVIF” for the same interface without understanding the architecture. The criterion should indicate which link is being specified and which function needs to be interoperable.
ONVIF and video surveillance integration can coexist in the same ecosystem
ONVIF interfaces can reduce proprietary integrations, but they must be coordinated with VMS, network, cybersecurity and other physical systems.
ONVIF’s history and broad adoption in video make integration between access and video surveillance a natural use case. ONVIF itself describes combinations between access profiles and video profiles.
In a design, this can allow door events to be correlated with video through standardized interfaces in parts of the architecture. However, complete integration between VMS and access control may require additional functions beyond the individual profiles.
The article Video Surveillance and Access Control: Integration, VMS and Design Criteria addresses this integration from a functional perspective; this content specifically addresses ONVIF interoperability.
Cybersecurity remains a design requirement
Interface standardization does not eliminate network risks. ONVIF devices are IP equipment and must be treated within the security architecture: segmentation, authentication, administrative credentials, TLS where applicable, firmware updates, hardening, certificate management and monitoring.
The profile defines interoperability for certain functions, not a complete cybersecurity policy for the facility. ONVIF maintains security requirements and mechanisms in its specifications, but the overall security level also depends on configuration and the implemented architecture.
How to specify ONVIF in access control without creating an empty requirement
A specification should not merely state “ONVIF compatible.” It can require:
- official conformance with Profile A, C or D according to the component’s function;
- clear identification of the device/client role;
- model and firmware/software listed in the official conformant products database;
- support for mandatory features and the conditional features required by the use case;
- documentation of functions that remain proprietary;
- behavior upon loss of communication;
- IP interface security requirements;
- evidence of interoperability in FAT and SAT;
- delivery of the conformance matrix and tested versions.
This format enables competition without turning “ONVIF” into a decorative word in the specification.
FAT should test functions, not merely device discovery
Finding a device on the network or receiving an ONVIF response does not prove that the functions required by the design are interoperable. The FAT should execute use cases associated with the required profile.
For Profile A, this may require validating configuration of credentials, schedules or rules. For Profile C, doors, states, commands and events. For Profile D, exchanges between peripheral and client for the contracted functions.
The test should record models, firmware/software versions, client, device, profile, exercised function, result and any limitations.
SAT must confirm integration in the real environment
In the field, the network, VLANs, firewalls, certificates, latency, controllers, doors and real applications can reveal issues not seen on the bench. The SAT should repeat critical functions on the installed topology.
Upgrades must also be checked. If conformance is tied to a firmware/software version and an update changes system components, the change management process needs to consider compatibility impacts.
When Profiles A, C and D should be included in Access Control System Design
The profiles should be considered when the interoperability strategy aims to reduce dependence on proprietary interfaces between components or platforms that effectively support ONVIF in this domain.
The Access Control System Design should determine at which interfaces standardization adds value, which profiles are required, which functions remain out of scope, and how conformance will be demonstrated. This allows ONVIF to be used as a verifiable technical requirement rather than as a generic substitute for an integration architecture.
Final considerations
ONVIF in access control is more specific than the generic expression “ONVIF product.” Profile A addresses configuration of rules, credentials and schedules; Profile C, doors, access points, events and alarms; Profile D, access peripherals.
Interoperability depends on compatible profiles, device/client roles, required features and actually conformant versions. When these elements are included in the specification and in FAT/SAT, ONVIF can reduce proprietary integrations and increase architectural freedom without creating a promise of compatibility beyond what the standard actually covers.
Official conformance and functional interoperability should be demonstrated in FAT and confirmed in SAT using the models and versions actually installed.
Technical references
[1] ONVIF. ONVIF Profiles — profile concepts and interoperability. Available at: https://www.onvif.org/profiles/
[2] ONVIF. Profile A — For access control configuration. Available at: https://www.onvif.org/profiles/onvif-profile-a/
[3] ONVIF. Profile C — For door control and event management. Available at: https://www.onvif.org/profiles/onvif-profile-c/
[4] ONVIF. Profile D — For access control peripherals. Available at: https://www.onvif.org/profiles/profile-d/
[5] ONVIF. Conformant Products — official database of ONVIF conformant products. Available at: https://www.onvif.org/conformant-products/
[6] ONVIF. Conformance Process — conformance requirements by profile and firmware/software version. Available at: https://www.onvif.org/profiles/conformance/
[7] IEC. IEC 60839-11-1:2013 — Electronic access control systems — System and components requirements. Available at: https://webstore.iec.ch/en/publication/3662
Frequently asked questions
The main ones are Profile A for credential, schedule and rule configuration; Profile C for door control and events; and Profile D for peripherals such as readers, sensors, locks and biometric devices.
No. They are complementary. Profile C addresses door control and events; Profile D addresses the access peripheral interface. A solution may use both.
No. ONVIF officially considers conformant those products registered in its Conformant Products database for the corresponding profile and firmware/software version.
No. OSDP normally operates in field communication between reader and controller, while ONVIF standardizes IP interfaces between devices and clients for specific functions. They can coexist in the same architecture.
FAT and SAT should execute the functions required by the profile, recording device, client, model, firmware/software, profile, use case and result. Simply discovering the device on the network does not prove functional interoperability.
