Government Responses to Vendor Questions.xlsx

Sheet1

Given the breadth of our proposed biometric device offerings across the applicable tracks, we are requesting additional time to complete our technical, compliance, supporting documentation, and pricing submissions to ensure that the information provided is complete and accurate. The additional time would allow us to conduct a thorough quality review and submit a comprehensive, fully responsive proposal.

Accordingly, we respectfully request that the proposal submission deadline be extended by 10 calendar days, to September 28, 2026, at 10:00 a.m. Eastern Time. This extension would enable us to provide a more thorough and accurate response while maintaining full compliance with the solicitation’s submission requirements.

Please confirm whether the Government will consider this request. If approved, we would appreciate issuance of an amendment reflecting the revised deadline.

(b) YES. A FIPS 140-3 validated module is acceptable.

(c). No. Due to DHS Policy, biometric data is PII and must be encrypted Attachments 3A/3B/3C/3D, DHS 4300A, DoDI 8500.01, and NIST SP 800-39 rows (FINGERPRINT-MER-35/37/38, FACE-MER-38/40/41, IRIS-MER-46/47/50, PALMPRINT-MER-40/42/43) Technical DHS Policy Directive 4300A, DoD Instruction 8500.01, and NIST SP 800-39 are organizational and system-level information security policies and risk management frameworks. They do not establish device-level technical specifications or a certification a hardware manufacturer can hold. Please clarify what the Government requires an Offeror to demonstrate for a YES response on these pass/fail rows. Is the intent that the device introduces no condition that would prevent an integrating system owner from maintaining compliance with these policies, or does the Government require some device-level artifact or attestation? If the latter, please identify the artifact. For purposes of the referenced MERs, a “Yes” response means the Offeror represents that the proposed device or device configuration supports, and does not introduce a condition that would prevent, an integrating Government system owner from maintaining compliance with the applicable security policies and risk management requirements.

The Government does not require a separate DHS 4300A, DoDI 8500.01, or NIST SP 800-39 “device certification” because no such general hardware manufacturer certification is identified in the solicitation. Instead, Offerors should provide device-level documentation or attestation sufficient to support the claimed “Yes” response.

Acceptable supporting information may include, as applicable:

* A manufacturer or Offeror attestation that the device configuration supports compliance with the cited security requirements;

* Description of device security features, including access controls, authentication support, encryption, logging, audit capability, secure configuration, and data protection features;

* Description of data storage, data transmission, data deletion, and external connectivity behavior;

* Identification of whether the device stores biometric data or other sensitive information locally;

* FIPS 140-2 or FIPS 140-3 cryptographic module information, if encryption is used or required;

* Secure configuration or hardening guidance;

* Patch, firmware update, vulnerability remediation, and end-of-support/end-of-life information;

* Software/firmware version information and relevant supply chain documentation;

* Documentation of any dependencies, limitations, or required configuration settings.

If a proposed device has no direct network connectivity, does not store biometric data, or relies on a host system for certain security functions, the Offeror should state that and explain how the proposed configuration supports integration into a compliant Government system.

Offerors should not modify the Attachment 3 checklist format. They should mark “Yes” only if they can provide supporting information for the proposed device configuration and should include the supporting explanation in the device’s technical documentation and/or the proposal's Technical Assumptions section.

Attachment 3A, FINGERPRINT-MER-3 and FINGERPRINT-MER-4; Attachment 3D, PALMPRINT-MER-5 and PALMPRINT-MER-7 Technical These requirements call for certification to, and collection in accordance with, the FBI Appendix F Image Quality Specifications of EBTS 11.X or above. Many devices currently in federal service hold Appendix F certification issued against an earlier revision of Appendix F, and the FBI Certified Product List does not always identify the EBTS revision associated with a given certification. Will the Government accept a current, unexpired Appendix F certification and CPL listing as satisfying these requirements irrespective of the EBTS revision in effect at the time of certification? If not, please identify the documentation the Government will accept as evidence of certification specifically at 11.X or above. The Government will accept a current FBI Appendix F certification and listing on the FBI Certified Product List (CPL) as satisfying the certification requirement in FINGERPRINT-MER-3 and PALMPRINT-MER-5, provided the certification applies to the offered device/model and meets the applicable FAP or palmprint certification requirements stated in the solicitation.

If the FBI CPL does not identify the EBTS revision associated with the certification, the Offeror should provide the best available documentation showing the current Appendix F certification and CPL listing for the offered device/model. Acceptable documentation may include the FBI CPL entry, certification letter, manufacturer certification documentation, test report, or other documentation that clearly links the offered model to the claimed Appendix F certification.

Separately, FINGERPRINT-MER-4 and PALMPRINT-MER-7 require the device to collect images in accordance with the applicable FBI Appendix F Image Quality Specifications of EBTS 11.X or above. For those requirements, the Offeror should identify in its supporting technical documentation how the offered device and associated software/firmware support capture, image quality, formatting, and output consistent with EBTS 11.X or above.

Accordingly:

* A current, applicable Appendix F certification and CPL listing may be used to support the Appendix F certification requirement.

* The Offeror remains responsible for representing that the proposed device collects images in accordance with the EBTS 11.X or above requirements stated in the MERs.

* If the Offeror has documentation specifically identifying EBTS 11.X or later compliance, it should provide that documentation.

* If the available FBI certification documentation does not state an EBTS version, the Offeror should provide the current CPL/certification documentation and explain the basis for its “Yes” response for EBTS 11.X or above compliance in the proposal Technical Assumptions section.

The Government may verify the claimed certification and compliance during evaluation, contract administration, or at the delivery order level.

Attachment 3A FINGERPRINT-MER-11; Attachment 3B FACE-MER-10; Attachment 3C IRIS-MER-20 Technical These Minimum Essential Requirements state that the device will be UL Certified. Will the Government accept certification by any OSHA-recognized Nationally Recognized Testing Laboratory, such as Intertek/ETL, TUV, or CSA, to the applicable product safety standard (UL/IEC 62368-1), as satisfying this requirement? Additionally, the requirement is phrased in the future tense as 'will be UL Certified' rather than as a present condition. Does the Government require the certification to be in effect at the time of proposal submission, or may an Offeror certify a commitment to obtain listing prior to first delivery? The Government will accept certification by UL or by another OSHA-recognized Nationally Recognized Testing Laboratory (NRTL), such as Intertek/ETL, TÜV, CSA, or another OSHA-recognized NRTL, when the certification is to the applicable product safety standard for the offered device configuration. This may include UL/IEC 62368-1 or another applicable product safety standard based on the device’s design, configuration, intended use, and operating environment.

For purposes of FINGERPRINT-MER-11, FACE-MER-10, and IRIS-MER-20, an Offeror should identify the certifying laboratory, applicable product safety standard, certification category, certified model or component, and any limitations in its supporting technical documentation.

An Offeror may mark “Yes” if the offered device configuration has UL certification at the time of proposal submission. Otherwise, devices currently in the development/testing/certification pipeline, once compliant with requirements, can be proposed in a future on-ramp period and/or modification of this IDIQ.

Attachment 3D, PALMPRINT-SPECIFIC-11; compared with FINGERPRINT-MER-11, FACE-MER-10, IRIS-MER-20 Technical UL certification appears as a pass/fail Minimum Essential Requirement on the Fingerprint, Face, and Iris tabs, but on the Palmprint tab it appears only on the Specific Requirements tab, which is not rated. Please confirm whether this difference is intentional. Please also confirm the resulting treatment of a multi-modal device under Attachment 3E: where a device combines palmprint with fingerprint, face, or iris, is UL certification pass/fail by operation of the other modality's MER tab? Confirmed. As currently drafted, UL certification is treated differently across the modality attachments.

For the Palmprint Track, UL certification appears in PALMPRINT-SPECIFIC-11, which is a Specific Requirement. Specific Requirements are not evaluated on a pass/fail basis under Factor 1. Accordingly, for a Palmprint Track proposal, UL certification is not a pass/fail MER unless the solicitation is amended to move or add that requirement to the Palmprint MER tab.

For the Fingerprint, Face, and Iris Tracks, UL certification appears as a Minimum Essential Requirement. Therefore, for those tracks, the applicable UL certification requirement is evaluated on a pass/fail basis under Factor 1.

For a Track 5 Multi-Modal device, the Offeror must complete the applicable MER tabs in Attachment 3E for each modality included in the proposed multi-modal configuration. If the proposed multi-modal configuration includes fingerprint, face, or iris, then the UL certification MER associated with that modality applies on a pass/fail basis for that modality. Therefore, a multi-modal device that combines palmprint with fingerprint, face, or iris must satisfy the UL certification MER for the applicable non-palm modality to receive a Pass for that modality under Factor 1.

If the multi-modal configuration includes palmprint, the palmprint UL item should be answered in accordance with its placement in the Attachment 3E Palmprint Specific Requirements tab, unless otherwise amended. Offerors should identify the UL certification basis for the complete offered configuration or applicable certified components in their supporting technical documentation.

Attachment 3A FINGERPRINT-MER-40; 3B FACE-MER-43; 3C IRIS-MER-52; 3D PALMPRINT-MER-45 Contractual These Minimum Essential Requirements state that the device supports Government data rights as per FAR 52.227-17, Rights in Data-Special Works. Special Works contemplates Government ownership of works first produced in performance of the contract. This IDIQ is for commercial products delivered with commercially available firmware and software development kits that are not first produced under the contract. Please clarify the scope of this requirement. Does it extend to an Offeror's pre-existing commercial firmware, embedded software, or SDK, or is it limited to biometric data and records captured by the device in performance of a delivery order? We note that G.5 provides the Delivery Order Contracting Officer will specify whether 52.227-14, 52.227-17, or agency-specific data rights clauses apply to an order, which suggests data rights are established at the order level rather than as a device attribute. The Government clarifies that the referenced MERs are intended to ensure that devices support the Government’s required data rights in Government-generated data, outputs, records, reports, and other deliverables produced under this IDIQ or an applicable delivery order, including biometric images, biometric transaction files, associated metadata, logs, and other records captured, generated, exported, or otherwise produced by the device in performance of a delivery order.

The requirement is not intended, by itself, to require transfer of ownership in an Offeror’s pre-existing commercial firmware, embedded software, commercial software, commercial SDKs, or other pre-existing intellectual property that was not first produced in performance of the contract. Rights in such pre-existing commercial products, firmware, embedded software, SDKs, documentation, and related technical data remain subject to the applicable FAR, HSAR, and any order-level license terms, data rights clauses, or agency-specific provisions.

The Government further clarifies that Section G.5 provides that the Delivery Order Contracting Officer will specify whether FAR 52.227-14, FAR 52.227-17, or agency-specific data rights clauses are applicable to a delivery order. Accordingly, specific data rights obligations will be established at the delivery order level. The MERs at Attachment 3A FINGERPRINT-MER-40, Attachment 3B FACE-MER-43, Attachment 3C IRIS-MER-52, and Attachment 3D PALMPRINT-MER-45 should be understood as requiring the device and associated functionality to be capable of supporting those Government data rights requirements when applicable, not as a blanket requirement that the Government obtain ownership of all pre-existing commercial firmware, embedded software, SDKs, or other commercial intellectual property.

Attachment 3B, FACE-MER-36 Technical This Minimum Essential Requirement states that the device shall meet and comply with DHS Facial Recognition Directive 026-11. Directive 026-11 governs the use of face recognition and face capture technology by DHS personnel and programs. Please clarify what a device manufacturer must demonstrate for a YES response, and please identify the publicly available version of the Directive against which Offerors should assess their devices. Offerors should support a “Yes” response by providing device-level information, as applicable, such as:

Description of the device’s face capture functionality;

Supported image quality controls and quality feedback;

Accuracy, performance, or test documentation available for the device or associated software;

Human operator controls, including any manual acceptance or override functionality;

Audit, logging, metadata, and transaction-record capabilities;

Data storage, retention, deletion, and export capabilities;

Access control, encryption, and cybersecurity features;

Documentation identifying whether the device performs facial recognition/matching or only facial image capture;

Any limitations, assumptions, or configuration dependencies relevant to DHS policy compliance.

The requirement does not require the Offeror to certify DHS’s operational use of the device or to make legal or policy determinations on behalf of DHS. It requires the Offeror to identify and document the capabilities of the proposed device configuration relevant to DHS’s ability to use the device consistent with applicable policy.

The requirement does not require the Offeror to certify DHS’s operational use of the device or to make legal or policy determinations on behalf of DHS.

Attachment 3D, PALMPRINT-MER-6 and PALMPRINT-MER-8 Technical These requirements call for compliance with the FBI Appendix P Image Quality Specifications at EBTS 11.X or above. Appendix P certification is distinct from Appendix F certification and is held by a materially smaller population of devices. Please confirm whether the Government requires a formal Appendix P certification listed on the FBI Certified Product List, or whether demonstrated compliance with the Appendix P image quality specifications, evidenced by test data, is sufficient for a YES response. The Government requires the proposed device to comply with the applicable FBI EBTS Appendix P requirements for palmprints and supplemental fingerprints, as stated in the applicable Attachment.

Unless the specific requirement expressly requires formal Appendix P certification or inclusion on an FBI Certified Product List for Appendix P, a formal Appendix P certification/listing is not required for a “Yes” response. Demonstrated compliance with the applicable Appendix P requirements, supported by appropriate documentation or test data, is sufficient.

Offerors claiming compliance should provide supporting documentation that substantiates the “Yes” response, such as:

* Test data demonstrating compliance with the applicable Appendix P requirements;

* Manufacturer technical documentation identifying Appendix P conformance;

* Independent laboratory or third-party test results, if available;

* Sample output files or transaction-format documentation, if applicable;

* Documentation showing support for the applicable EBTS 11.X or later palmprint/supplemental fingerprint requirements;

* Any FBI certification, product listing, or other third-party validation, if available.

If a separate requirement requires FBI Appendix F certification or inclusion on the FBI Certified Product List, that separate requirement must be satisfied as written. Appendix F certification does not automatically satisfy Appendix P compliance, and Appendix P compliance does not replace any separately stated Appendix F certification requirement.

Offerors should identify in their supporting technical documentation the applicable EBTS version, device model, software/firmware version, test method, and any limitations or configuration dependencies for the claimed Appendix P compliance.

Attachment 3C, IRIS-MER-15 Technical This requirement states that the device iris recognition capabilities shall meet the requirements in the latest version of the NIST Iris Exchange (IREX). IREX is a NIST evaluation program that assesses submitted algorithm implementations rather than certifying capture hardware. Please clarify what the Government requires for a YES response: participation and results in a specific IREX evaluation, conformance of captured images to the IREX image specifications, or another basis. If a specific IREX evaluation is intended, please identify it. The Government acknowledges that NIST Iris Exchange (IREX) is a NIST evaluation program and is not, by itself, a hardware certification program for iris capture devices.

For purposes of IRIS-MER-15, the intended reference is the latest applicable NIST Iris Exchange guidance identified in the solicitation, including NIST IREX-X, as applicable to iris image capture and image quality. A “Yes” response means the Offeror is representing that the proposed device or device configuration produces iris images and related outputs that conform to the applicable IREX image requirements, quality considerations, or test-relevant specifications for the proposed use.

The Government does not require participation in a specific NIST IREX algorithm evaluation as a condition of satisfying IRIS-MER-15, unless the proposed device includes iris recognition, matching, or algorithmic capabilities and the Offeror is relying on IREX participation or results to support its claimed compliance. If the Offeror relies on a specific IREX evaluation, the Offeror should identify the evaluation, participant name, algorithm/version, date, and relevant results.

Offerors should support a “Yes” response by identifying the basis for compliance in their supporting technical documentation, such as:

The applicable IREX version or guidance used;

The iris image specifications, quality metrics, or output characteristics supported by the device;

Whether compliance is achieved by the capture device, associated software, SDK, or host application;

Any IREX evaluation results, if applicable;

Any limitations, assumptions, or configuration dependencies.

If the proposed device only captures iris images and does not perform iris recognition or matching, the Offeror should explain how the captured images conform to the applicable IREX image capture or image quality expectations rather than providing algorithm evaluation results.

Attachment 3A FINGERPRINT-MER-24/26/27; 3B FACE-MER-29/31/32; 3C IRIS-MER-39/41/42; 3D PALMPRINT-MER-29/31/32 Technical These Minimum Essential Requirements address Mean Time Before Critical Failure, Mean Time To Repair, and Operational Availability. SIC Biometrics requests clarification on three points. (a) The Operational Availability formula as stated in the attachments reads Ao = ((Mean Time Before Critical Failure) / ((Mean Time Before Critical Failure) x (Mean Time To Repair))) X 100. Because the MTBCF term appears in both the numerator and the denominator of a product, the expression reduces to 100 divided by MTTR, and the MTBCF term cancels. As written, the result is independent of device reliability and can exceed 100 percent where MTTR is less than one hour. The conventional formulation is Ao = MTBCF / (MTBCF + MTTR). Please confirm whether the Government intends the conventional formulation, and if so whether the attachments will be corrected by amendment. If Offerors are to apply the formula exactly as printed, please confirm that the resulting values will be interpreted accordingly. (b) These requirements are phrased as an obligation on the vendor to provide information rather than as a device performance threshold, and no minimum value is specified for any of the three metrics. Please confirm that a YES response signifies the Offeror's commitment to furnish the figures, and that no particular value is required to pass. (c) Section M.1.1 states that no documentation will be reviewed under Factor 1 beyond the submitted MER tab, and the MER tab accommodates only a YES or NO entry. Please identify where these figures are to be submitted. Should they be included within the ten-page technical specification package under Factor 2, or provided separately? Please also confirm whether the Government requires figures derived from a particular reliability standard or test methodology. (a) Yes. The Government intends the conventional Operational Availability formula:

Ao = [MTBCF / (MTBCF + MTTR)] x 100

Offerors should use this formula when providing Operational Availability information. The formula printed in the attachments, which uses MTBCF multiplied by MTTR in the denominator, is not the intended calculation. If necessary, the Government will correct the affected attachments by amendment. Offerors should not calculate Ao using the formula exactly as printed.

(b) Confirmed. The applicable MERs require the Offeror to provide information for MTBCF, MTTR, and Operational Availability. They do not establish a minimum required MTBCF, maximum required MTTR, or minimum required Ao value for purposes of passing Factor 1. A “Yes” response signifies that the Offeror is providing the requested information for the proposed device configuration. Offerors remain responsible for ensuring that any submitted figures are accurate, supportable, and applicable to the proposed device configuration.

(c) Offerors shall enter “Yes” or “No” in the applicable MER tab in Attachments 3A through 3E. The underlying MTBCF, MTTR, and Ao figures should be provided in the supporting technical documentation for the proposed device, such as the technical specification package submitted under Factor 2. Offerors should clearly identify the device, requirement number, metric, value, assumptions, and calculation method so the Government can associate the information with the applicable MER.

The Government does not require that the MTBCF, MTTR, or Ao figures be derived from a particular reliability standard or test methodology at the IDIQ proposal stage. Offerors should identify the basis for the figures provided, such as manufacturer/OEM data, reliability testing, warranty or support history, field performance data, commercial reliability data, or a documented engineering estimate. If a particular methodology or test standard is used, the Offeror should identify it in the supporting technical documentation

Appendix F contains the FBI CJIS Image Quality Specifications. Appendix P contains specifications for transmitting palm prints and supplemental fingerprints. Accordingly, the Government’s intent is for offered palmprint devices to support palmprint capture and output consistent with the applicable EBTS requirements, including the applicable image quality requirements in Appendix F and the palmprint transmission and formatting requirements in Appendix P.

Offerors should provide documentation demonstrating that the proposed palmprint device meets the applicable FBI EBTS requirements for palmprint capture, image quality, and palmprint transmission/formatting. If the device is certified or listed under an applicable FBI certification or product list, the Offeror should identify the certification, model, and supported capture type.

To the extent the wording in PALMPRINT-MER-6 suggests that Appendix P itself contains the Image Quality Specifications, the Government will clarify the requirement by amendment if necessary.

Attachment 3D Technical With respect to requirement PALMPRINT-MER-11, does a device that provides the image quality score via a function call into the device SDK meet the requirements of the MER since the software that calls this function can easily implement the ability to manually accept such a fingerprint image? No. This should be able to be completed without the need to utilize the SDK. Under FAR 52.227-17, existing commercial software and third-party SDKs do not have to grant unlimited rights to the Government; they can retain their commercial license terms. The FAR Special Works framework explicitly states that these provisions do not apply to limited rights data or restricted computer software. Because commercial software and third-party SDKs are typically developed at private expense, they fall under the definition of restricted computer software rather than "special works"

Consequently, the Government acquires them under their customary commercial licenses, provided those terms are consistent with federal law and satisfy the agency's needs.

Attachment 3D Technical With respect to requirement PALMPRINT-MER-13, requirement PALMPRINT-MER-5 requires Appendix F certification which, as far as we know, has historically only been granted to touch based devices. The two ways we know of to capture latent fingerprints are via touchless methods or flatbed scanning of latents that have been converted to sheet stock. Does requirement PALMPRINT-MER-13 contemplate importing images scanned from sources other than the device itself? Please discuss the envisioned data flow necessitating this requirement. PALMPRINT-MER-5 and PALMPRINT-MER-13 are separate requirements and should be addressed independently.

PALMPRINT-MER-5 requires the offered palmprint device to meet the applicable Appendix F certification requirement stated in Attachment 3D. Offerors must satisfy that MER as written to receive a “Pass” for Factor 1, unless the solicitation is amended.

For PALMPRINT-MER-13, the Government understands that latent print workflows may involve images that are not captured directly by the same live-scan device. The requirement may be satisfied by a proposed device configuration that can import, receive, process, or otherwise support latent print images that have been digitized or scanned from another source, provided the capability is part of the offered configuration and the Offeror clearly describes the method, supported formats, limitations, and associated software or workflow.

The envisioned data flow is generally as follows:

1. A latent print image is captured, scanned, or digitized using an appropriate source;

2. The image is imported or made available to the offered device configuration or associated software;

3. The configuration supports processing, viewing, quality review, metadata association, formatting, or packaging of the image, as applicable;

4. The resulting image or transaction is exported or made available in the applicable supported format, if required by the proposed use case or delivery order.

At a minimum, the device or associated device software should capture and provide the metadata required by the applicable facial image exchange format or standard supported by the device, such as IXM, FBI EBTS, or DoD EBTS, as applicable to the proposed configuration.

The Government requires metadata across three operational layers: (1) Biometric Capture & Sensor Metadata, (2) Audit Logging & Transactional Metadata, and (3) Proposal Submission / File Control Metadata. The offeror should list what metadata the system provides.

Examples of image metadata may include, as applicable:

* Date and time of capture, including Date Time Group (DTG);

* Device make, model, and serial number;

* Camera or sensor identifier;

* Software, firmware, application, SDK, or driver version used for capture;

* Image format, file type, image size, and resolution;

* Compression information, if applicable;

* Capture mode, capture settings, or capture distance, if available;

* Image quality score or quality assessment output, if supported;

* Transaction, encounter, or file identifier, if generated by the device or associated software;

* Image type or subject orientation information, if applicable;

* Metadata fields required by the applicable EBTS, IXM, DoD, or delivery order interface.

FACE-MER-4 does not establish a separate Government-unique metadata schema at the IDIQ proposal stage unless otherwise specified in a delivery order or interface control document. Offerors should describe in their supporting technical documentation what metadata the proposed device captures, where the metadata is stored or exported, and whether it is embedded in the image file, included in a transaction file, maintained in associated metadata, or made available through an API, SDK, log, or other output.

For purposes of FINGERPRINT-MER-11, FACE-MER-10, and IRIS-MER-20, an Offeror should identify the certifying laboratory, applicable product safety standard, certification category, certified model or component, and any limitations in its supporting technical documentation.

An Offeror may mark “Yes” if the offered device configuration has UL certification at the time of proposal submission. Otherwise, devices currently in the development/testing/certification pipeline, once compliant with requirements, can be proposed in a future on-ramp period and/or modification of this IDIQ.

The Government does not intend to require that the DTG be included only in the Transaction Control Number (TCN), unless the applicable transaction standard, interface specification, or delivery order requires that approach. The TCN may contain date/time information if required by the applicable standard or Government interface, but FACE-MER-11 requires the DTG, make, model, and serial number to be captured and associated with the developed file.

If the proposed device produces an Electronic File Transmission (.eft) output file, the Offeror should include the DTG, make, model, and serial number in the appropriate EFT fields, metadata fields, transaction fields, or associated record structure consistent with the applicable EBTS, IXM, or DoD specification. If the applicable output format does not provide a specific field for one or more of these elements, the Offeror should explain how the information is captured and associated with the file, such as through metadata, an audit log, a manifest, an application record, or another linked output.

Offerors should describe in their supporting technical documentation:

* Whether the device outputs .eft files;

* Where the DTG, make, model, and serial number are captured;

* Whether those elements are embedded in the file, included in transaction metadata, or maintained in an associated record;

* Whether the TCN includes DTG information;

* Any dependencies on host software, middleware, or Government applications.

For an Android phone-based configuration, these capabilities may be provided through the Android operating system, OEM device management tools, the biometric capture application, an administrative or support mode within the application, etc.

Requirement: The vendor shall provide best practices documentation for regular maintenance and cleaning of the device.

Requirement: The Vendor shall provide information on the devices Mean Time To Repair (MTTR). MTTR = Corrective Maintenance Time/Number of Failures.

Requirement: The vendor shall provide information of the devices Operational Availability (Ao). Ao = ((Mean Time Before Critical Failure) / ((Mean Time Before Critical Failure) x (Mean Time To Repair))) X 100. Technical Are these requirements applicable to a vendor who only leverages Android COTS devices? If so, how should they be annotated in Attachment 3B response? Yes. FACE-MER-30, FACE-MER-31, and FACE-MER-32 apply to the proposed facial capture device configuration, including configurations that leverage Android COTS devices.

For purposes of these requirements, the “device” is the complete offered configuration proposed for the Face Track. This may include the Android COTS hardware, biometric capture application, firmware, required peripherals, mounts, power accessories, and any other components necessary for the configuration to operate as the proposed facial biometric capture device.

Offerors should complete Attachment 3B using the required “Yes” or “No” response format. Offerors should not enter “N/A” unless the Government revises the Attachment to allow that response.

Offerors should respond as follows:

FACE-MER-30: Mark “Yes” if the Offeror provides best practices documentation for regular maintenance and cleaning of the proposed Android COTS-based configuration.

FACE-MER-31: Mark “Yes” if the Offeror provides MTTR information for the proposed configuration, including the basis for the value or estimate.

FACE-MER-32: Mark “Yes” if the Offeror provides Operational Availability information for the proposed configuration, including MTBCF, MTTR, assumptions, and calculation method.

Ao = [MTBCF / (MTBCF + MTTR)] x 100

For FACE-MER-32, Offerors should provide the device’s Operational Availability using the corrected formula above, together with the underlying MTBCF and MTTR values and any relevant assumptions used in the calculation.

For…