Technical specifications and baselines

Last updated: 06 July 2026

This section outlines the core technical specifications, standards, and baseline configurations for CFT.

File transfer process

1. Agencies upload files to the platform using HTTP APIs or SFTP.
2. By default, files are scanned for malware. Depending on the configuration, scanning may be bypassed or additional Content Disarm and Reconstruction (CDR) scanning may be done to ensure secure transmission.
3. Depending on security needs, files may be encrypted or decrypted during the transfer.
4. Once cleared, files are delivered to the receiver.

File formats

By default, CFT supports all file formats.

However, for CDR and Scan Bypass features, check the supported file lists first:

• CDR Supported File Types

• Scan Bypass Supported File Types

Note: CFT is unable to verify file extensions of items contained within zipped files.

File size

CFT supports HTTP and SFTP file transfers with the following file size limits.

Transfers exceeding 1 GB

If you need to transfer files larger than 1 GB: → submit a service request for CFT to review and approve your use case.

• With scanning: You may request an increase to up to 5 GB
• Without scanning: Higher limits may be allowed, subject to CFT approval, through the Scan Bypass feature.

Zero-Byte Files

CFT supports the transfer of zero-byte files.
However, if your workflow requires handling these files explicitly, you must configure the appropriate handling logic on your tenant system.

File scanning behaviour

• Default malware scanning: By default, CFT scans files for malware. However, you can configure your workflow to bypass the scanner, subject to specific terms and requirements. Refer to Scan Bypass.

• Password-protected files: By default, CFT cannot process the transfer of password-protected files and folders. However, you can configure your workflow to allow the transfer of password-protected files by bypassing the scanner, subject to specific terms and requirements. Refer to Scan Bypass.

• Zipped files: CFT is able to scan zipped files and files that are encrypted using a CFT key. CFT can scan files stored within zip or archive files, including those nested up to five layers deep.

  Limitations:

  1. Maximum of 1000 files within a single zipped file. Each embedded object* within a file is counted as a single, individual file. For example, you can send 1,000 files with no embedded objects or 1 file that contains up to 999 embedded objects.

     You can enable Scan Bypass to include more than 1000 files in a zipped file.

  2. Total size of extracted files cannot exceed 1 GB.

  Notes:

  • Microsoft Office documents are considered as archived files.
  • An embedded object* is a file, such as an image, video, audio, or code (like macros or scripts), that is inserted or integrated within another file. For example, a Word document might contain images, spreadsheets, or macros embedded inside it. These embedded objects are counted as separate files during scanning. If you have a zip file that contains 1 Word document with 3 images and 2 embedded Excel files, the scanner will count that as 6 files in total.

File transfer baseline performance

CFT operates as a central platform, with all agencies sharing the same underlying infrastructure, allowing for cost-effective operations and scalability.

However, when multiple agencies upload and download files at the same time, it can lead to high-concurrency situations that may impact system performance.

Transfer performance factors

• Larger files take longer to process.
• Complex files (like zip archives or Office documents with macros) may require more thorough scanning.
• Concurrent high usage periods can slow down processing times.

Estimated file processing times

Performance factors

Key considerations for baseline performance

• Network Speed: Upload and download times vary based on agency network speed and system load.

• Concurrency: High usage can increase transfer times by up to 30%, especially for larger files.

• File Size: Larger files (500MB–1GB) take longer to process at all stages.

• File Type Impact on scanning or CDR time:

  • Microsoft Office Documents

    • Undergo deeper inspection (e.g., macro detection, data validation)

  • 20-30% longer processing time than simple files

  • Example: 10MB file may take up to 3 minutes for scanning and CDR

  • Complex File Types

    • Zip Archives: 30-50% longer scan times due to unpacking and individual file scanning
    • PDFs and Media Files: Longer processing for embedded malware checks
    • Example: 1GB zip file may take up to 10 minutes for full scan and CDR

• Scan and CDR Considerations:

  • Encryption/decryption adds processing time
  • Larger files and high concurrency (50+ uploads) can increase scan times by up to 50%
  • Stringent security policies may further slow processing

• Throughput and Concurrency:

  • Multiple simultaneous uploads can degrade performance
  • Concurrency limits:
    • Small files: 300
    • Medium files: 100
    • Large files: 50
  • Exceeding these limits may cause system slowdowns

Transfer logs and status

The table lists the different methods for checking the file transfer status and their availability.

HTTPS API Rate Limiting

CFT enforces a rate limit on API requests originating from the same IP address within a specified time period.

File encryption

CFT ensures that data is encrypted both at-rest and in-transit.

When in transit, HTTPS and SFTP protocols provide encryption. HTTPS utilises SSL/TLS to encrypt the transmitted data, while SFTP, being a secure iteration of FTP, employs the SSH protocol for file transfer, ensuring that data remains secure during transit.

Files are stored in CFT’s Amazon S3 bucket while awaiting scanning and retrieval. Amazon S3 employs 256-bit AES encryption, which is enabled for all of CFT’s S3 buckets, ensuring that data remains encrypted while at rest - whether it’s awaiting scanning or retrieval.

Additionally, CFT also supports PGP and SLIFT (Legacy).

Interactive uploads

While CFT is optimised for system-to-system file transfers, interactive uploads via government devices can be configured when necessary.

COMET device support

Before using COMET for CFT file transfers, agencies must obtain risk acceptance approval due to potential data classification concerns:

• Risk assessment: Evaluate the possibility of sensitive data exposure when transferring between COMET and CFT systems

• Management approval: Obtain formal risk acceptance from agency management

• Sensitive High data: For Sensitive (High) data transfers, additional requirements apply. See Sensitive High transfers.

• SFTP via COMET: Due to COMET’s MAC algorithm limitations (umac-128-etm@openssh.com and umac-128@openssh.com not supported), use the following SFTP command format: sftp -v -o MACs=hmac-sha2-256 sftp-pw.in.cft.stack.gov.sg.

Known Issue
Users connecting from GSIB or Comet machines may encounter a Corrupted MAC on input error when using these MAC algorithms:

umac-128@openssh.com
umac-128-etm@openssh.com

Resolution
If you encounter this error, please reconnect using one of the other supported MAC algorithms. For example:sftp -o MACs=hmac-sha2-256 sftp.in.cft.stack.gov.sg

Security compliance and continuous assurance

CFT undergoes formal security testing prior to production go-live to ensure required security controls are in place. In addition, CFT is subject to regular independent security assessments, including annual external Vulnerability Assessment and Penetration Testing (VAPT).

Identified findings are addressed through remediation, mitigation, or formal risk acceptance in accordance with established security governance processes.

Security assurance is maintained as an ongoing lifecycle practice, supported by continuous monitoring, regular patching, vulnerability management, and periodic security reviews. CFT operates within the Government on Commercial Cloud (GCC) environment in alignment with applicable Whole-of-Government and IM8 security requirements.