Cryptographic Discovery for File Shares

Most cryptographic discovery stops at the network. It inventories TLS endpoints, certificates and PKI, and produces a respectable picture of cryptography in motion.

Meanwhile, decades of encrypted material sits on file shares. Password-protected spreadsheets. PGP-encrypted exports from a system nobody has touched in years. Java keystores dropped next to an application’s config. LUKS volume images in a backup folder. Encrypted archives that somebody sent, somebody saved, and nobody has thought about since.

This is exactly the material that harvest-now-decrypt-later targets. An attacker copying an encrypted archive today does not need to break it today. They need to keep it until the key-wrapping around it is breakable. Data with a ten or twenty year confidentiality requirement, sitting in a file nobody is tracking, is the clearest example of the problem there is.

You cannot put it on a migration roadmap if you do not know it exists.

Finding an encrypted file is the easy part. Knowing what it means for your migration is the point.

Each finding is scored for quantum risk and flagged for harvest-now-decrypt-later exposure with a stated rationale. A PKCS#12 or JKS key container is treated as high risk and quantum-vulnerable, because key containers overwhelmingly hold RSA and ECC key material and that cannot be confirmed from metadata alone. A password-protected Office document is high risk, because the document key is wrapped. An encrypted archive is medium, because whether it is genuinely exposed depends on how its data key is wrapped, and the finding says so rather than guessing.

That rationale travels with the finding into the CBOM, so the team doing the remediation can see why something was prioritised.

File share findings are not a separate report. They enter the same Cryptography Bill of Materials as your network TLS, PKI, HSM, cloud KMS, database and code repository findings, addressed as smb://host/share/path or nfs://host/export/path so every finding is traceable to exactly where it lives.

That matters because the question a regulator asks is not "what is on your file shares". It is "where is your quantum-vulnerable cryptography, all of it, and what is your plan". One inventory answers that. Six tools producing six spreadsheets does not.

Does Quantum Sentinel read the contents of files on our shares?

No. The scanner reads the first 512 bytes of each file to identify its format, and discards everything it does not need. File contents are never read in full, never copied off the share and never transmitted. The only exception is a narrow one: for compound-file Office documents it checks the container’s directory for an EncryptionInfo stream name to confirm the document is genuinely encrypted, which is a structural check and not a read of the document.

What access does a file share scan need?

Read access. For SMB, a username, password and domain with permission to read the share you want scanned; a read-only service account is the right way to run it. For NFS, a UID and GID that the export will accept. NFS uses AUTH_SYS, so no NFS password is created or stored.

Do you support CIFS, or SMB1?

The scanner speaks SMB dialects 2.0.2 through 3.1.1. SMB1, the dialect properly called CIFS, is not supported. It has been deprecated for years and is disabled by default on current Windows Server releases, so in practice the shares people describe as "CIFS shares" are SMB2 or SMB3 shares and are scanned normally. If you are genuinely still running SMB1, that is a finding in its own right before it is a discovery problem.

Which NFS version is supported?

NFS v3. NFS v4 exports are not currently scanned.

Does it detect encrypted files by extension?

No, and that is deliberate. Detection is based on the file’s content signature. Files with misleading extensions are found; files with alarming extensions that turn out to be plaintext are not reported.

How does it handle very large shares?

A scan is bounded at 200,000 files and a directory depth of 25, and you can scope it to a subtree rather than an entire share. Directories the service account cannot read are skipped rather than failing the scan.

Can it run in an air-gapped environment?

Yes. Quantum Sentinel deploys on-premises and supports fully air-gapped installation. No finding leaves your environment.

Does it work on cloud object storage as well?

The file share scanner covers SMB and NFS shares. Cloud key management and cloud environments are covered by separate Quantum Sentinel integrations that feed the same CBOM.