Hardware Security Modules (HSMs) for the Ministry of Interior of Montenegro, including delivery, offload, on-site installation and training services

New amendment added #3: Dear potential bidders, UNOPS SEEMCO hereby amends one of the tender requirements as follows:Removing the following requirement: Firmware / patches: to be included, security patches within 30 days of CVERequirement to be inserted:Firmware / patches: The contractor will be expected to make every reasonable effort to address identified Common Vulnerabilities and Exposures (CVE) and provide security patches as quickly as possible.Please note that the following tender documents have been altered to reflect the amendment, and new versions of documents are available:- 2 RFQ Section 2 Schedule of Requirements - ver.1- 3 RFQ Section 3 Returnable Bidding Forms - ver.1

New clarification added: (Continued)4. Question / Clarification Request  – HSM Backup Copies Requirement:The requirement specifies maintaining two backup copies for each HSM. In the proposed architecture, two HSMs operate in an HA configuration, which would typically imply a total of eight backup copies. To optimize the solution while maintaining the required level of resilience, we propose deploying two dedicated backup HSM devices per production HSM, each capable of securely storing a minimum of two independent backup copies. This results in a total of four backup devices holding all required copies. Could you please confirm whether this approach would be considered compliant with the requirement, provided that the total number of backup copies and their integrity and recoverability are fully ensured?Answer:The requirement clearly specifies that, within a system comprising two HSM devices, a minimum of two backup copies must be provided for each individual HSM device (“Copies per unit: Minimum 2”), where the term “unit” refers to each physical HSM device, regardless of its role in the high-availability (HA) architecture.The implementation of an High Availability (active-passive) configuration relates exclusively to ensuring continuity of the production service and does not affect the required number or the method of creating backup copies of cryptographic keys. Accordingly, the HA architecture cannot be considered a substitute for the required backup mechanism, nor does it reduce the prescribed number of backup copies.Furthermore, the specification explicitly provides that key backup and recovery must be implemented using the defined mechanisms (smart cards or dedicated tokens and an M-of-N quorum). The use of additional HSM devices as backup media or as a substitute for the prescribed backup copies is neither envisaged nor implicitly assumed. In accordance with the above, the proposed model involving additional dedicated backup HSM devices for each production HSM does not correspond to the backup concept defined in the Schedule of Requirements, as it changes the nature of the prescribed mechanism and introduces an infrastructure-based approach that is not envisaged by the tender requirements. In conclusion, the requirement remains unchanged: for each of the two HSM devices, at least two backup copies must be provided in accordance with the prescribed mechanism (M-of-N and smart cards or dedicated tokens), with full capability for secure key recovery, while the HA architecture remains a separate functionality intended solely to ensure high availability of the system.5. Question / Clarification Request  – CVE Remediation Timeframes:It is not feasible to guarantee a fixed 30-day resolution timeframe (including patch or firmware update delivery) for newly discovered Common Vulnerabilities and Exposures (CVEs). This is due to several factors beyond immediate control, including:·         Complexity and impact assessment: Each vulnerability must undergo thorough analysis to determine its applicability, severity, and potential impact on different product versions, configurations, and customer environments.·         Development and validation requirements: Remediation often requires code changes, followed by extensive testing (functional, regression, security, and interoperability) to ensure that the fix does not introduce instability or unintended side effects.·         Product lifecycle and dependencies: Some vulnerabilities may affect third-party components or legacy architectures, where fixes depend on upstream vendors or require architectural adjustments.·         Compliance and quality assurance processes: Security updates must meet strict quality and certification standards, particularly for regulated environments, which can extend validation timelines.·         Risk-based prioritization: Remediation timelines are prioritized based on severity, exploitability, and real-world threat intelligence.Nevertheless, the company makes every reasonable effort to address identified vulnerabilities as quickly as possible, following industry best practices for vulnerability management, and ensuring timely mitigation, communication, and delivery of fixes where feasible. For these reasons, remediation timelines are managed on a case-by-case basis rather than under a fixed SLA. In light of the above, we kindly request that the requirement for a guaranteed 30-day remediation timeframe be removed from the RFQ.Answer: In the light of provided justification, a guaranteed 30-day remediation timeframe for Common Vulnerabilities and Exposures (CVE) will be removed as the requirement. Still, the contractor will be expected to make every reasonable effort to address identified Common Vulnerabilities and Exposures (CVE) and provide security patches as quickly as possible.(end) 

New clarification added: Dear bidder representatives, UNOPS SEEMCO had received  request for clarifications as below. You may find the clarification after each question.1. Question / Clarification Request  – PKCS#11 Version RequirementThe requirement in RFQ indicates PKCS#11 standard v2.40, while propose solution is compliant with PKCS#11 v2.20 with some extensions to 2.30 and 2.40In the vast majority of enterprise and financial use cases, applications rely only on a subset of PKCS#11 functions and mechanisms that are already fully supported in earlier versions of the standard (including v2.20). As a result, the practical impact of supporting a higher PKCS#11 version is typically limited, unless there is a specific requirement for newer or less commonly used mechanisms introduced in later versions. From an interoperability and functional perspective, compatibility with widely used PKCS#11 features is generally more relevant than the nominal version number, and solutions compliant with v2.20 continue to meet the requirements of most existing applications and integrations.Therefore, could you please clarify whether support for PKCS#11 v2.40 is a mandatory requirement for your use case, or if compliance with PKCS#11 v2.20 with extension is acceptable? Alternatively, we kindly request consideration to remove or relax this requirement from the tender specifications, unless specific v2.40 features are explicitly required.Answer: A certain set of standard PKCS#11 functionalities are available in earlier versions of the standard, including version v2.20. However, the requirement for support of PKCS#11 v2.40 has been defined with the objective of ensuring full interoperability, long-term compatibility, and compliance with modern HSM devices, middleware components, and application systems that will be integrated throughout the lifecycle of the solution. In addition, considering the requirements related to high availability, transparent failover, a unified logical HSM access model for PKCS#11 clients, as well as compliance with the FIPS 140-3 Level 3 standard, UNOPS SEEMCO considers it justified to retain the requirement for PKCS#11 v2.40 or higher. Accordingly, the requirement remains unchanged. Support for PKCS#11 v2.40 remains a mandatory requirement.2. Question / Clarification Request – Luna Client Licensing ScopeMiddleware working with HSM (inc. PKCS#11 library) licensing is based on the number of application servers establishing connections to the HSM.Could you please clarify the expected number of servers that will connect to the HSM infrastructure, in order to determine the required number of Luna Client licenses?Additionally, any temporarily connected servers, admin stations, or test/development servers do not need to be counted.Answer: The planned system architecture foresees approximately 15 application servers that may establish connections to the HSM infrastructure. However, considering that the proposed solution represents a central cryptographic infrastructure that must provide high availability, transparent failover, integration of existing and future systems, as well as long-term scalability, a licensing model based on restrictions of the number of application servers or individual client connections is not acceptable. The bidder is required to provide appropriate licensing for all middleware and client components necessary for the uninterrupted operation of the proposed solution in production, High Availability/Disaster Recovery, administrative, development, and test environments. Licensing models that do not limit future system expansion in terms of the number of application servers, integrations, or PKCS#11 clients will be considered acceptable.3. Question / Clarification Request – Warranty vs. Support & Maintenance DurationThe RFQ specifies:·         A minimum 3-year hardware warranty, and·         A minimum 5-year availability of components and spare parts following the warranty period.However, the support and maintenance constraint is defined as 3 or 5 years.Could you please clarify whether the supplier is expected to:·         Provide support and maintenance services aligned with the full 8-year period (3 years warranty + 5 years parts availability), or·         Limit support and maintenance strictly to the selected 3- or 5-year contract period, with only parts availability ensured afterward?This clarification will help ensure proper alignment of the proposed support model and costing.Answer: The equipment supplied will be warranted in conformity with the contractual terms and the related service level agreement, during a minimum of 3 years from the date of completed installation and commissioning. After the expiration of the warranty period, the supplier is obliged to ensure the existence of the components and parts for the installed equipment for the period of further 5 years minimum.(responses to Clarification Requests 4 and 5 will follow)

New clarification added: Dear bidder representatives, UNOPS SEEMCO had received a suggestion for an additional extension of the bid submission deadline for the additional 7 days due to the complexity of the subject procurement subject. UNOPS had accepted the suggestion and amended the tender, allowing new bids submission deadline to be 18 May 2026 at 14 UTC time. 

New amendment added #2: Dear potential bidders, UNOPS SEEMCO hereby extends the deadline for bid submission - the new deadline will be 18. May 2026. at 16h Podgorica/Montenegro time (14h UTC).Thank you for your interest in participation.

New amendment added #1: Dear potential bidders, UNOPS SEEMCO hereby extends the deadline for bids submission - new deadline will be 11. May 2026. at 16h Podgorica/Montenegro time (14h UTC).Thank you for your interest in participation.

New clarification added: Question;We kindly request an extension of the deadline for submitting our bid. Due to the public holiday tomorrow, we are unable to obtain the necessary price quotations and finalize our offer by Monday. Thank you for your understanding and consideration. Response:Dear potential bidders, UNOPS is already considering an extension of the deadline. If we process it, all companies that have expressed the interest via eSourcing platform will have available informmation about extension through a tender amendment.Regards