An access-control proposal can say “encrypted reader” without explaining which connection is encrypted. That missing boundary matters. A credential communicates with a reader; the reader communicates with a controller; management software communicates with other system components. Evidence about one connection does not establish the security of the others.
For the reader-to-controller connection, legacy Wiegand and OSDP offer different capabilities. OSDP supports two-way communication and Secure Channel encryption. An OSDP-capable device, however, is not evidence that an installed connection actually uses Secure Channel. Buyers need a documented configuration and an acceptance record for the proposed combination.
This guide explains the distinction and offers an owner-facing evidence framework. It does not prescribe wiring, security keys, attack tests, lock behavior or emergency-egress arrangements. No equipment was independently tested for this article, and no outside professional review is claimed. Sources were checked October 28, 2026.
Start with the reader-to-controller connection
The Security Industry Association’s OSDP overview describes an access-control communications standard connecting controllers and peripheral devices such as readers. Its capabilities include bidirectional communication, supervision and Secure Channel using AES-128 encryption. The public overview lists version 2.2.2, released in October 2024, and identifies international standard IEC 60839-11-5:2020.
SIA’s 2021 Wiegand comparison describes the traditional reader-data interface as one-way and unencrypted. That is the relevant comparison here: the reader-to-controller data path. A legacy installation may have additional alarm circuits, proprietary equipment or other measures; those should be documented separately rather than assumed from the interface name.
Ask the supplier to draw the actual path for each door. Label the reader, controller, intermediate modules and management connection. Record the protocol on each segment. A diagram containing an unexplained converter or an “existing wiring” cloud is not yet a complete answer about encryption boundaries.
Map the protection boundaries
Use the following table as a proposal-review worksheet. These are separate evidence requests, not claims that every access system has the same architecture or features.
| Boundary | Question for the supplier | Evidence to retain |
|---|---|---|
| Credential to reader | Which credential technology and authentication method are used? | Exact credential and reader compatibility documentation |
| Reader to controller | Which interface is installed, and is Secure Channel active where specified? | Door-specific protocol and configuration record |
| Controller to management | What protects this separate connection? | Architecture and vendor documentation for that connection |
| Administration and service | Who can make changes and maintain the system? | Approved roles, service responsibilities and change procedure |
| Door and egress hardware | Who approves the physical and life-safety design? | Applicable design approvals and separate acceptance records |
| Intermediate modules | Where does each protocol begin and end? | Segment-by-segment drawing with retained legacy portions labeled |
For example, a proposal may document Secure Channel between a reader and controller while saying nothing about credential authentication. Mark the latter question unanswered. Do not translate the first fact into “the badges cannot be copied.” Similarly, a statement about the management network is not proof of the reader connection’s configuration.
“End-to-end encrypted” needs named endpoints. Ask the author to replace that phrase with a specific connection and supporting evidence. If the scope cannot be established, keep the narrower statement in the procurement record and leave the broader claim unaccepted.
Capability is different from enabled Secure Channel
SIA’s February 2026 implementation checklist distinguishes OSDP communication from Secure Channel and calls for checking supported functions and firmware. This makes “OSDP supported” an initial compatibility question, not the final encryption check.
A concrete documentation example is the Axis A4120-E manual, dated March 2026. It describes standard OSDP operation separately from Secure Channel configuration and documents a secure mode that refuses unencrypted communication. Those distinctions demonstrate why model-specific instructions matter. They are not a recommendation of that product, a statement about other manufacturers’ defaults, or verification of a deployed system.
In a proposal, separate three entries: what the hardware supports, what the project requires, and what acceptance demonstrated. A datasheet answers the first. The approved scope answers the second. A dated, door-specific record answers the third. Leaving any entry blank should remain visible as an open item.
Also ask what the approved service process permits after a reader replacement or configuration reset. An acceptance report should identify unresolved exceptions and who owns them. Do not place actual encryption keys, installer credentials or sensitive configuration exports in a public article, ordinary customer handout or unrestricted project tracker.
Read verification claims at the right level
SIA’s OSDP Verified Products page describes conformance testing against the standard and performance profiles. It also explicitly cautions that verification does not automatically establish interoperability. Device verification and acceptance of a specific installed combination answer different questions.
Have the supplier identify the exact reader and controller models, relevant firmware, claimed profile and supporting listing or manufacturer statement. Keep a copy with its date. Then ask which functions the actual combination will deliver and how those functions will be accepted. A similar model name or a general manufacturer logo is not a substitute for the specified configuration.
This article did not query the complete verified-product directory or establish a listing for any named device. The Axis documentation example above is evidence of a configuration distinction only. It should not be presented as a conformance certificate or a purchasing shortlist.
Procurement language can be precise without promising universal compatibility: “Supplier to document the proposed model and firmware combination, required Secure Channel operation, supported project functions and acceptance evidence.” Attach the agreed exceptions instead of treating a standards acronym as an all-purpose guarantee.
Treat migration as a documented project
An upgrade inventory should identify each door’s present reader, controller interface, intermediate equipment and available documentation. Give unknowns their own status. “Existing equipment retained” is a scope decision that needs an owner, not proof that the retained portion meets the new requirement.
SIA’s implementation guidance calls for evaluating cabling for RS-485 use, checking power requirements and staging equipment before installation. It does not justify a blanket promise that every Wiegand cable can be reused. Have the responsible installer assess the actual cable, topology, equipment instructions and site conditions. This article supplies no universal distance, wire-size or termination recipe.
For a phased conversion, distinguish completed doors from pending doors and identify the protocol on every retained segment. A converter requires its own boundary description: which side uses which interface, and what protection is documented on each side? Do not describe a whole chain as Secure Channel merely because one segment uses it.
Before work begins, agree on affected doors, service windows, authorized personnel, operating arrangements and the process for returning doors to service. Handle lock and emergency-egress decisions through the project’s responsible design and approval process. A reader communications upgrade is not an egress design approval.
Accept evidence, not a beep or a brochure
SIA’s April 2026 troubleshooting guidance warns that a reader’s light or beep does not establish valid OSDP communication. It recommends documenting firmware and configuration and validating communication, including Secure Channel. A successful credential presentation alone therefore leaves important questions unanswered.
Define the acceptance scope before the demonstration. The owner’s representative should know which doors and functions were checked, which records will be delivered and which limitations remain. Specialist diagnostic work belongs with authorized personnel using approved methods; owners need the findings and their scope, not a public collection of sensitive traces or secrets.
| Acceptance item | What the record should identify |
|---|---|
| Equipment baseline | Door ID, reader and controller models, firmware and date |
| Protocol and protection | Actual reader-controller interface and documented Secure Channel state |
| Required functions | Agreed functions, observed results and any unsupported features |
| Supervision and alerts | Supported events included in the approved test scope and their results |
| Exceptions | Unchecked doors, unresolved findings, responsible party and resolution target |
| Sign-off and handover | Authorized participants, report location and service contact |
Avoid a report that says only “access control passed.” A more useful entry names the door, configuration, agreed checks and result. If a function was not checked, say so. If evidence is unavailable, keep the item open instead of substituting a sales statement.
Keep handover records useful after installation
Maintain a controlled baseline and a change log. Record what changed, who authorized it and whether the change affects the accepted configuration. Reader replacements, firmware changes and controller substitutions should trigger a review of the relevant evidence rather than silent reliance on the original report.
Our structured-cabling handover checklist helps organize cable identifiers, drawings and test reports. Those records support the physical infrastructure handover. Keep the access-control protocol and Secure Channel evidence alongside them as a separate record; a cable report does not establish encryption state.
Assign responsibility for restricted configuration backups, key custody and vendor escalation. Record where authorized staff can retrieve those materials without copying the secret material into the general handover index. The index should identify the custodian and recovery process, with access controlled through the organization’s approved arrangements.
The practical purchasing question is straightforward: can the supplier identify the protected connection, show the accepted configuration and explain how it will be maintained? A bounded answer with documented exceptions is more useful than an unsupported promise that a protocol makes the entire building secure.
Before you choose the locks those readers control, see our guide to electronic door locks, egress, fire alarm release and power-failure behavior.
Frequently asked questions
Does OSDP support prove that Secure Channel is enabled?
No. Treat hardware capability, project requirements and the installed Secure Channel state as separate entries. Request configuration evidence and a dated acceptance record for the actual reader-controller combination.
Does Secure Channel protect every connection in an access system?
No. Reader-to-controller protection does not establish credential-to-reader authentication, management-network protection or physical door security. Identify and document each boundary separately.
Do OSDP Verified devices automatically work together?
No. SIA distinguishes device conformance verification from interoperability. Require evidence for the specified model, firmware, functions and installed combination rather than relying on a general standards claim.
Can an existing reader cable always be reused for OSDP?
Do not assume so. Have the responsible installer evaluate the actual cable and system requirements against the applicable equipment instructions. Keep reuse decisions and unresolved limitations in the project record.
Sources and editorial scope
Primary references: SIA OSDP overview, SIA Verified Products explanation, SIA implementation checklist, February 10, 2026, SIA troubleshooting guidance, April 28, 2026, Axis A4120-E manual, March 2026, and SIA legacy Wiegand comparison, November 9, 2021.
The public source pages support this explanation; the complete paid OSDP specification was not reviewed. The worksheet and graphic are ClearTrade Report editorial frameworks, not a certification, product test, site assessment or security guarantee. No reproduced manufacturer images, affiliate recommendations or professional-review claims appear here.
AI tools assisted research organization, drafting and production. ClearTrade Report Editorial Team checked the cited sources and edited the final article. Graphic: original ClearTrade Report editorial diagram; no third-party image assets.
Need a qualified professional?
Trusted Pros uses visible license-verification states and never ranks paid listings above unpaid listings.