Parking equipment is network-connected infrastructure. Pay stations process cardholder data. LPR systems retain license plate images tied to timestamps and payment records. PARCS management software sits on the same networks as a facility’s access control, building management, and sometimes property management systems. The cybersecurity posture of that equipment is a legitimate procurement concern — and most parking RFPs don’t address it adequately.

The gap isn’t intentional. Most procurement teams adapt general equipment RFP templates to parking, and those templates predate the era of IoT-connected PARCS. The result is RFPs that specify gate arm cycle times and terminal EMV certification but say nothing about network segmentation, data retention limits, or API authentication requirements.

This guide covers the specific cybersecurity language buyers should add to parking equipment RFPs.

Why Cybersecurity Belongs in the RFP — Not the Contract

The instinct is to handle security requirements during contract negotiation or system design. That instinct is wrong for two reasons.

First, vendor selection happens before contract negotiation. If a vendor’s system architecture can’t support your security requirements, discovering that after selection means either accepting a weaker security posture or restarting procurement. The RFP is where you filter.

Second, vendors respond to what they’re scored on. An RFP that doesn’t require cybersecurity documentation produces proposals that don’t include it. Adding security requirements to the RFP scoring criteria forces vendors to address them in their responses — which gives you actual information for comparison rather than vague commitments made during negotiation.

Payment Security: PCI DSS v4.0 Requirements

Any parking system that accepts card payments falls within scope of PCI DSS. As of March 31, 2025, PCI DSS v4.0 requirements are mandatory, replacing the prior v3.2.1 standard. Several of the new requirements are directly relevant to parking equipment procurement.

What to write into your RFP

Terminal certification: Require that all payment terminals are listed on the PCI SSC’s Validated Payment Terminals list. Do not accept vendor claims of compliance without a current listing reference.

P2PE certification: Require Point-to-Point Encryption certification from a PCI-listed P2PE solution. P2PE ensures cardholder data is encrypted at the point of interaction and decrypted outside the parking operator’s environment, significantly reducing PCI scope.

Payment page integrity (Requirement 11.6.1): For any web-based or mobile payment component, require vendors to document how they meet the PCI DSS v4.0 payment page integrity monitoring requirement. This applies to hosted payment pages and mobile payment applications.

Tokenization workflow: Require that no full Primary Account Numbers (PANs) are stored in the parking management system. Require documentation of the tokenization provider and confirmation that token storage meets PCI DSS requirements.

Vendor’s own compliance status: Require a current PCI DSS Report on Compliance (ROC) or Self-Assessment Questionnaire (SAQ) for the vendor’s own environment. Ask which SAQ level they complete and why.

Network Segmentation Requirements

Connected parking equipment — pay stations, LPR cameras, intercoms, PARCS servers, access control readers — should not share network segments with general corporate IT infrastructure, property networks, or internet-facing systems without documented segmentation controls.

PCI DSS Requirement 1 mandates network controls that separate the cardholder data environment from other network segments. For parking equipment, this means specifying how the PARCS network is isolated.

RFP language for network segmentation

Include the following as technical requirements:

  • VLAN isolation: Payment terminals and PARCS management servers must operate on dedicated VLANs, isolated from tenant networks, building management systems, and general IT infrastructure. Require vendors to document proposed VLAN architecture in their response.
  • Firewall rules: Require vendors to specify which ports and protocols are required for system operation, and provide a firewall rule set proposal. Accept only least-privilege configurations — no “allow all” rules on PARCS VLANs.
  • Remote access controls: All vendor remote access for support and maintenance must traverse a documented, auditable VPN or jump server. Require documentation of the remote access architecture and confirmation that persistent remote access is not used.
  • Penetration testing: For systems with PCI scope, require vendors to confirm that their equipment and software undergoes annual penetration testing and that results are available under NDA to customers who request them.

Open Architecture and API Security

Open architecture mandates — requiring that PARCS systems use documented, vendor-neutral APIs rather than proprietary protocols — have become standard in better-written parking RFPs. They prevent vendor lock-in and enable integration with enforcement, validation, and mobile payment platforms from different vendors.

The security dimension of open architecture is less often specified: open APIs are also attack surfaces. An RFP that requires open APIs without specifying authentication requirements creates a security liability.

API security specifications

  • Authentication: Require OAuth 2.0 authentication for all API endpoints. Do not accept API key-only authentication without additional controls.
  • Encryption in transit: Require TLS 1.2 minimum (TLS 1.3 preferred) for all API communications. Reject proposals that support unencrypted HTTP for any operational endpoint.
  • Event webhooks: Require that webhooks for plate read events, payment confirmations, and device health alerts are authenticated and include payload signing so receiving systems can verify event origin.
  • API documentation: Require complete API documentation as a deliverable — not a post-contract add-on. If a vendor cannot provide documentation during the procurement process, that is a signal about long-term integration support.

Access Control Reader Security: OSDP

If the parking PARCS includes access control readers (RFID credential readers, HID readers, or similar), specify the communication protocol between readers and the PARCS controller.

The legacy Wiegand protocol transmits credential data in plain text with no encryption or authentication. OSDP (Open Supervised Device Protocol), developed by the Security Industry Association, provides encrypted, bi-directional communication between readers and controllers. OSDP Secure Channel uses AES-128 encryption and is required in federal government applications under FIPS 201 and related standards.

For most commercial parking applications, OSDP v2 with Secure Channel enabled is the appropriate specification. Write this into the RFP as a minimum requirement for any access control reader component. Verify that the PARCS management software supports OSDP reader integration — some older PARCS platforms are Wiegand-only, which would conflict with an OSDP requirement.

LPR Data Retention Limits

License plate recognition systems generate a continuous record of vehicle movements — timestamped, location-tagged, and increasingly searchable. That data has privacy implications, and increasingly, legal ones. Several states have enacted or are considering legislation restricting how long LPR data can be retained by private parking operators.

RFP specifications for LPR data

  • Retention policy: Require vendors to document their system’s configurable data retention limits. Specify a maximum retention period appropriate to your jurisdiction and use case — 30–90 days is a reasonable commercial baseline for unpaid transaction records; shorter periods may be appropriate for general traffic records.
  • Data deletion: Require that the system supports automated deletion of records that exceed the retention period, and that deletion is logged.
  • Access controls: Require role-based access controls for LPR data, with audit logging of who accessed records and when.
  • Data export format: Require that LPR data can be exported in a standard format (CSV or JSON) and that no vendor lock-in prevents data portability at end of contract.

Vendor Security Documentation: What to Request

Beyond system specifications, ask vendors to provide:

  • A current SOC 2 Type II report or equivalent third-party security audit for any SaaS component
  • Disclosure of any security incidents or data breaches involving parking PARCS products in the prior 24 months
  • Patch and firmware update policy: how frequently are updates issued, how are they delivered, and what is the average time-to-patch for critical vulnerabilities?
  • Incident response contact: a named point of contact and documented escalation procedure for security incidents

Vendors who cannot provide these documents during procurement are telling you something about their security program. Treat missing documentation as a scored deficiency, not a defeatable condition.

Scoring Security in Your Evaluation

Security requirements should appear in two places in your RFP scoring framework: as pass/fail criteria and as scored criteria.

Pass/fail (disqualifying if not met):

  • Current PCI-listed terminal certification
  • Documented P2PE certification
  • TLS 1.2 minimum on all API endpoints

Scored criteria (weighted in evaluation):

  • Completeness of network segmentation documentation (5–10% of technical score)
  • OSDP Secure Channel support (if access control is in scope)
  • SOC 2 report or equivalent for SaaS components
  • LPR data retention configurability and audit logging

Weighting security at 10–15% of the total technical score is appropriate for most commercial parking procurements. Facilities with regulatory obligations, healthcare proximity, government tenants, or high transaction volumes should weight security higher.

A Practical Starting Point

The most common failure mode in parking cybersecurity procurement is treating security as a compliance checkbox rather than an operational specification. The specifications above are not about compliance theater — they’re about selecting vendors whose systems can operate securely in connected infrastructure environments.

Write these requirements into your RFP before issuing it. Vendors who respond with documented, specific answers to security requirements are vendors who have thought through the problem. Vendors who respond with vague assurances are vendors who haven’t.

The editors of Parking Equipment Guide