1-05. Submittal Form- VENDOR RESPONSE SHEET.CV SCMS.070225.docx
DOCX document 40 KB Posted
- Solicitation number
- UDOT260002MP
- Issued by
- Utah
About this file
This document is a Vendor Response Sheet for the Utah Department of Transportation (UDOT) Connected Vehicle Security Certificate Management System (CV SCMS) procurement. The solicitation seeks qualified firms to provide a comprehensive security certificate management system for connected vehicle environments, with the intent to award multiple contracts. The contract will have an initial term of 5 years with an option to extend for an additional 5 years. Vendors will be evaluated on a 330-point scoring system across categories including general system information, ability to meet project requirements, additional scope and features, system demonstration, and cost.
The procurement focuses on selecting a vendor capable of developing a scalable, secure digital certificate management system for connected vehicle cybersecurity, with mandatory requirements including proven experience in developing such systems, ability to integrate with existing vehicle communication protocols, and maintaining all state data in U.S. data centers. Vendors must demonstrate capabilities in issuing digital certificates, supporting multiple root Certificate Authorities, providing secure administrative interfaces, ensuring high system availability (99.9% monthly uptime), and supporting interoperability across different vehicle communication systems. The evaluation process involves a detailed scoring rubric where vendors can earn points based on the comprehensiveness and quality of their proposed solutions, with a minimum threshold of 112.5 points required to advance to a system demonstration phase.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| 4-04. Submittal Form- Attachment B- Utah IT Standard Terms and Conditions- with check fields.docx | DOCX document | |
| 10-0. AMENDMENT 1 2025-07-29.doc | DOC document | |
| 2-03. Submittal Form- Attachment A- Utah Standard Terms and Conditions- with check fields.docx | DOCX document | |
| 8-01. RFP Solicitation Information- CV SCMS- AMENDED.doc | DOC document | |
| 6-07. Submittal Form- Vendor Setup Form.pdf | ||
| 9-06. Submittal Form- VENDOR PRICING SHEET.CV SCMS- AMENDED.docx | DOCX document | |
| 3-08. Submittal Form- Business Confidentiality- check fields.doc | DOC document | |
| 5-02. Scope of Work.CV SCMS.docx | DOCX document | |
| 7-0. AMENDMENT 1 2025-07-29.doc | DOC document |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
VENDOR RESPONSE SHEET
Utah Department of Transportation (UDOT)
CONNECTED VEHICLE SECURITY CERTIFICATE MANAGEMENT SYSTEM
Instructions Technical Proposal Requirements and Evaluation Technical Proposals will be scored based on the vendor responses to each of the sections in the “Vendor Response Sheet”, as described herein. Those total scores, summed for each of the Categories indicated, will be weighed according to the table below.
Vendors who achieve at least a 50% score (112.5 points out of 225 possible) in the general system and technical scoring areas (Categories A, B, and C in the table below) will be invited to demonstrate their system in a virtual meeting.
Category
| Percent of Total Points |
| Points Possible |
| A |
| General System Information (Section 2 on the Vendor Response Sheet) |
| 9.1% |
| 30 |
| B |
| Ability to Meet Project Requirements (Sections 3 through 7 on the Vendor Response Sheet) |
| 54.5% |
| 180 |
| C |
| Additional Scope and Features (Section 8 on the Vendor Response Sheet) |
| 4.5% |
| 15 |
| System Demonstration |
| 15.2% |
| 50 |
| Cost |
| 16.7% |
| 55 |
| TOTAL POINTS POSSIBLE |
| 100% |
| 330 |
To be considered in this evaluation, the vendor and their system must meet the requirements listed as “Mandatory” in the Stage 1 table below. Compliance documentation or narrative must be offered in the cell beneath each requirement. If a vendor cannot meet the mandatory requirement to UDOT’s satisfaction based on the responses provided, they will be deemed non-responsive and ineligible for further consideration.
The vendor must indicate their capabilities to meet each general system and technical requirement listed in Stage 2: General System Information and Technical Response Categories A, B, and C tables, below. An indication of the vendor’s ability to satisfy these requirements must be inserted in the “Explanation” cell beneath each requirement or, if indicated, in an optional attachment. Brief explanations about how the system will do so may also be offered. Scoring of each item will be based on these explanations. If a vendor needs additional development effort to meet specific requirements, they must indicate the time needed beyond a Notice to Proceed (NTP) to meet that requirement in the “Explanation” cell.
Each technical requirement will be given a score, by the evaluators, between 0 and 5, based on the following rubric:
(a) Five (5) points (Excellent): The proposal addresses and exceeds the requirements or criteria for that feature;
(b) Four (4) points (Good): The proposal addresses the requirements or criteria for that feature and, in some respects, exceeds them;
(c) Three (3) points (Satisfactory): The proposal addresses the requirements or criteria for that feature in a minimum satisfactory manner;
(d) Two (2) points (Unsatisfactory): The proposal addresses the requirements or criteria for that feature in a partial or less than complete way;
(e) One (1) point (Poor): The proposal inadequately addresses the requirements or criteria for that feature or provides incomplete information; or
(f) Zero (0) points (Fail): The proposal fails to address the requirements or criteria for that feature or indicates it will not provide the feature.
A weighting factor is shown next to each evaluation item in the “Weighting Factor” column. The total score given to each item will be multiplied by this weighting factor to result in the total awarded points for that item.
The vendor may offer additional scope or features beyond what is defined herein in the section labelled “Additional Scope and Features”.
General system descriptions or explanations that provide useful background may be inserted in the section labelled “Category A: General System Information”, with a five-page limit, and will be scored.
Vendor Name
Stage 1: Mandatory Vendor Qualifications (Pass/Fail)
| Item |
| Type |
| Requirement Description |
| Evaluation |
| 1.1 |
| Mandatory |
| Proven experience in developing and deploying digital certificate management systems for connected vehicle environments based on relevant industry standards (ISO, SAE, NIST, etc.) related to connected vehicle cybersecurity. (This experience need not be in the U.S.) |
| Pass/Fail |
Compliance Documentation:
| 1.2 |
| Mandatory |
| Demonstrated capability to design scalable, secure, and high-performance SCMS systems. |
Pass/Fail
Compliance Documentation:
| 1.3 |
| Mandatory |
| Demonstrated ability to integrate with existing vehicle communication protocols and third-party systems. |
| Pass/Fail |
Compliance Documentation:
| 1.4 |
| Mandatory |
| Ability to maintain all state data in data centers operating in the United States and shall perform all vendor services involving access to state data from within the United States, per Attachment A, Utah IT Terms and Conditions, Section 26, paragraphs d and k. |
| Pass/Fail |
Compliance Documentation:
| 1.5 |
| Mandatory |
| Ability to support multiple root Certificate Authorities (CAs) via the elector mechanism (There could be as few as one CA - such as during initial deployment). |
| Pass/Fail |
Compliance Documentation:
Stage 2: General System Information and Technical Response Category A: General System Information (30 points possible) Vendor shall insert a general system description or explanation that provides useful background of their system, with a five-page limit. In addition to a general description, the vendor shall address the following five items:
· Describe the administrative platforms and systems that are necessary to enroll and manage certificates and how it is hosted.
· Describe any optional platforms that are offered to assist in the management of certificates, but which are not required for full operation of the system.
· Identify potential risks with this project and propose mitigations to those risks
· Describe high-level project schedule and capabilities to begin work within 14 calendar days after post-award project kick-off meeting
· Indicate acceptance of liability for damages caused by an exposure of the private key for the Certificate Authority, including all certificates impacted by such an event.
| Item |
| Type |
| Requirement Description |
| Weighting Factor |
| 2.1 |
| Scored |
| General System Information |
| 6 |
Category B: Ability to Meet Project Requirements General System Requirements (45 Points Possible)
| Item |
| Type |
| Requirement Description |
| Weighting Factor |
| 3.1 |
| Scored |
| Ability to configure the system to support UDOT’s connected vehicle operations. |
| 2 |
Explanation:
| 3.2 |
| Scored |
| Ability to maintain a secure administrative interface. |
| 1 |
Explanation:
| 3.3 |
| Scored |
| Ability to provide a Service Level Agreement (SLA) to include, at a minimum: |
· Monthly up-time of at least 99.9%
· Online incident response time of one hour to respond to a request for assistance and one day to resolve the incident.
Explanation:
| 3.4 |
| Scored |
| Results of interoperability testing performed during an industry event, such as an OmniAir Plugfest. |
| 1.5 |
Explanation or Attachment:
| 3.5 |
| Scored |
| Ability to provide UDOT an OpOrgID (OID) under its base arc within six months after the publishing of CTI 4501 v02 |
| 0.5 |
Explanation:
| 3.6 |
| Scored |
| Ability to implement industry best practices for secure certificate management and cryptographic techniques, support Public Key Infrastructure (PKI) standards for certificate management, and ensure compliance with industry cybersecurity standards and frameworks, including IEEE 1609.2.1, ISO/SAE 21434, UNECE WP.29, NIST SP 800-53, and applicable portions of CTI 4501 that are reasonably achievable at this time. |
| 2 |
Explanation:
| 3.7 |
| Scored |
| Ability for system to support IPv4 and IPv6. |
| 1 |
Explanation:
Certificate Issuance, Management, and Authentication (65 Points Possible)
| Item |
| Type |
| Requirement Description |
| Weighting Factor |
| 4.1 |
| Scored |
| Ability to issue digital certificates to V2X end entities, including onboard units (OBUs), roadside units (RSUs), backend systems at the Traffic Operations Center, and related systems. |
| 2 |
Explanation:
| 4.2 |
| Scored |
| Ability to support initial enrollment (or reenrollment) / provisioning of end entity devices with Pseudonym, Identity, and Application certificates, including a private key, an Enrollment Certificate, and other features necessary for the full operation of the devices within the CV SCMS. (UDOT recognizes that “support” of enrollment means that the UDOT team will perform the work.) |
· Ability to provide UDOT and their team, including designated consultants, a detailed procedure and workflow for the initial bootstrapping and enrollment / provisioning of end entity devices.
· Ability to provide two-days of on-site support and up to 40 hours of remote support for initial enrollments / reenrollments.
Explanation:
| 4.3 |
| Scored |
| Ability to support the applications and messages shown in this Scope of Work with appropriate PSID and SSP and to provide security profiles for these applications. |
| 1 |
Explanation:
| 4.4 |
| Scored |
| Ability to scale the system as the number of end entities increases, supporting thousands of devices. |
| 1 |
Explanation:
| 4.5 |
| Scored |
| Ability for the system to be compatible with RSU and OBU devices currently in the UDOT system, as described in the Scope of Work. (Vendor shall indicate which other RSU and OBU hardware they are currently compatible with.) |
| 2 |
Explanation:
| 4.6 |
| Scored |
| Ability to provide secure storage and retrieval of certificates with automated renewal processes and a process for certificate top-off from an SCMS server. |
| 1 |
Explanation:
| 4.7 |
| Scored |
| Ability to provide other key files associated with SCMS operation such as a Certificate Trust List (CTL) and Certificate Revocation List (CRL). |
| 1 |
Explanation:
| 4.8 |
| Scored |
| Ability to conform to the pending SCMS Manager policy, within a year of the implementation of that policy, to enable the use of validated messages at intersections which meet the requirements. (SCMS Manager is currently developing a policy whereby connected intersections can be tested to demonstrate compliance with CTI 4501; an intersection which is compliant will be considered “validated” and an enrollment certificate with certain SSPs will indicate that the intersection has been validated.) |
| 1 |
Explanation:
| 4.9 |
| Scored |
| Ability to provide real-time, low-latency validation of certificates to verify authenticity and prevent unauthorized access. |
| 1 |
Explanation:
| 4.10 |
| Scored |
| Ability to support misbehavior identification and certificate revocation in accordance with SAE J3287 at a future date when SCMS Manager policies are updated and adopted. |
| 0.5 |
Explanation:
| 4.11 |
| Scored |
| Ability to support enrollment of revoked or malfunctioning devices after restoration of functionality. |
| 0.5 |
Explanation:
Interoperability and Integration with Existing Systems (25 Points Possible)
| Item |
| Type |
| Requirement Description |
| Weighting Factor |
| 5.1 |
| Scored |
| Ability to support interoperability across multiple root authorities, allowing trust to be established and broken as needed with no requirement for physical contact with enrolled devices as defined in IEEE 1609.2.1. |
| 2 |
Explanation:
| 5.2 |
| Scored |
| Ability to issue security certificates that are compatible/interoperable with other vendors’ SCMS systems as defined in IEEE 1609.2.1. |
| 2 |
Explanation:
| 5.3 |
| Scored |
| Ability to interface with existing V2X maintenance and data management platforms, including providing an API which allows an external system to query the latest data for end entity SCMS health, and to V2X communication infrastructure for the transfer of certificates. |
| 1 |
Explanation:
| 5.4 |
| Informational (not scored) |
| If vendor proposes to provide certificates to end entity devices that are not from ISS, vendor shall describe their acceptance of, and high-level approach to: |
· creating a detailed interoperability test plan for approval by UDOT,
· Demonstrating interoperability of their certificates with current ISS-provisioned devices by enrolling 10 RSUs and 5 OBUs (selected by UDOT) with their certificates and causing those RSUs and OBUs to successfully interface with ISS-provisioned devices for a period of three weeks in accordance with the test plan,
· Providing a report of the results of the interoperability demonstration to the satisfaction of UDOT,
· And providing detailed instructions on how to replace ISS certificates on an end-entity device with Vendor’s certificates, if this process is different from the initial enrollment process.
Explanation or Attachment:
User Interface and Reporting (25 Points Possible)
| Item |
| Type |
| Requirement Description |
| Weighting Factor |
| 6.1 |
| Scored |
| Ability for system to provide a secure and intuitive user interface for system administrators to manage and monitor certificate statuses. |
| 2 |
Explanation:
| 6.2 |
| Scored |
| Ability for system to provide multiple-user access to the user interface to allow UDOT to supply certificates to end entity devices owned by other agencies within the state while restricting access for those agencies to information on their certificates and data. |
| 1 |
Explanation:
| 6.3 |
| Scored |
| Ability for system to provide comprehensive reporting tools for tracking certificate lifecycles, renewals, and security events. |
| 1 |
Explanation:
| 6.4 |
| Scored |
| Ability for system to support the creation of audit logs and event history for compliance purposes. |
| 0.5 |
Explanation:
| 6.5 |
| Scored |
| Ability for system to provide reports on operational and maintenance activities, device performance and outages. |
| 0.5 |
Explanation:
Training and Support (20 Points Possible)
| Item |
| Type |
| Requirement Description |
| Weighting Factor |
| 7.1 |
| Scored |
| Ability to provide comprehensive training materials for administrators and end-users regarding the SCMS implementation, operation, and integration within UDOT’s Connected Vehicle and ITS architecture. (Provide a list of documentation that will be provided). |
| 2 |
Explanation:
| 7.2 |
| Scored |
| Ability to provide ongoing technical support and system maintenance, including updates and patches, including a description of vendor’s ongoing on-line and phone support and maintenance services, including typical response times, system update schedules, and service-level agreements (SLAs). |
| 2 |
Explanation:
Category C: Additional Scope and Features (15 Points Possible)
| Item |
| Type |
| Requirement Description |
| Weighting Factor |
| 8.1 |
| Scored |
| Vendor shall describe additional scope and features which can be provided that are not listed above. UDOT will have the option to select any of these features at its discretion. |
| 3 |
Explanation or Attachment:
Vendor Response Sheet Page 2 of 2
File details come from the government source that posted it. Updated .