Unencrypted data is information stored or transmitted without cryptographic protection, making it readable if intercepted or accessed by an attacker. In application and supply chain environments, this often includes credentials, tokens, personal data, and internal system details that should remain protected both at rest and in transit.
What Unencrypted Data Means in Practice
Unencrypted data is not only a confidentiality problem, it also changes the security posture of the system carrying it. If information is readable while stored or in transit, then anyone who can access the file, database, backup, packet, log, or pipeline step can inspect the contents without defeating cryptography first.
That matters because the exposed material is often more than ordinary content. Credentials, tokens, personal data, internal endpoints, and configuration details can all become immediately useful to an attacker once they are visible. In a supply-chain context, plaintext secrets can propagate through code repositories, build logs, CI/CD jobs, and shared artifacts before anyone notices.
Where Unencrypted Data Commonly Appears
Practically, unencrypted data shows up in two places: at rest and in transit. At rest includes disks, object storage, databases, snapshots, backups, export files, and temporary working directories. In transit includes application calls, API traffic, messaging, file transfer, and internal service-to-service communication.
The most damaging cases are usually not obvious user files. They are the supporting materials that systems generate around them, such as logs, crash dumps, diagnostic exports, environment files, and build outputs. A single plaintext secret in one of those locations can create a larger exposure than the original application data.
This is one reason supply-chain security guidance treats plaintext secrets as a recurring failure mode. NHIMG’s Ultimate Guide to Non-Human Identities notes that 96% of organisations store secrets outside secrets managers in vulnerable locations, including code, config files, and CI/CD tools.
Why Encryption Changes the Risk Profile
Encryption does not make data invulnerable, but it raises the effort required to read it and helps limit the damage from interception, theft, or accidental exposure. Without it, possession of the storage medium or network traffic can be enough to reveal sensitive content immediately.
That difference is especially important for shared environments. Cloud storage, application logs, backup systems, and integration platforms often have many operators and automated processes with indirect access. If the content is unencrypted, the trust boundary is much wider than most teams assume.
For data in motion, encrypted transport is usually the baseline protection against passive interception and some forms of man-in-the-middle abuse. For data at rest, cryptographic protection helps separate physical or administrative access to the system from readable access to the information itself.
How Teams Should Think About Exposure and Control
Unencrypted data should be treated as a design and handling issue, not just a storage issue. The key question is whether the information can be read by parties who are not supposed to see it, including internal users, service operators, third parties, and attackers who gain limited footholds.
Practitioners should pay particular attention to secrets and credentials because plaintext exposure of those values often converts a data-handling problem into an access problem. Once a token, key, or password is readable, it can be reused, replayed, or embedded into further abuse, which makes the original exposure much more consequential.
The control goal is therefore broader than “turn on encryption.” It is to ensure sensitive data is encrypted in the places where exposure would change the outcome, and that plaintext copies are not created unnecessarily in logging, packaging, transfer, or testing workflows.
Risk and Threat Considerations
Unencrypted data creates direct exposure because any compromise of the storage location, transmission path, or adjacent tooling can reveal the underlying content immediately. That is especially serious when the exposed material includes credentials, tokens, or personal data, because the same incident can become both a data breach and an access compromise.
Failure mechanism: Attackers, insiders, or downstream systems gain readable access through interception, misconfiguration, weak permissions, exposed logs, stolen backups, or plaintext artifacts in build and delivery systems.
Impact: The result can include unauthorized disclosure, account takeover, lateral movement, privacy harm, regulatory exposure, and rapid reuse of exposed secrets before remediation is possible.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS Control 3 — Data Protection | Unencrypted data is a core data protection issue affecting data at rest and in transit. |
| Recommendation — Encrypt sensitive data in storage and transit, and reduce plaintext exposure in logs, exports, and backups. | ||
| NIST CSF 2.0 | PR.DS — Data Security | PR.DS covers protection of information through encryption and safeguarding of data integrity and confidentiality. |
| PR.AC — Identity Management, Authentication and Access Control | Plaintext secrets and tokens directly affect access control because they can be reused for unauthorized access. | |
| PR.PT — Protective Technology | Encryption is a protective technology that reduces exposure when data is stored or transmitted. | |
| Recommendation — Apply PR.DS controls to protect sensitive data with encryption and limit plaintext handling paths. Restrict access to sensitive data and secret material so exposed plaintext cannot be easily reused. Use protective technologies such as transport and storage encryption for sensitive information. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Secrets Management and Rotation | Plaintext secrets in data stores and pipelines are a direct NHI governance failure when machine credentials are exposed. |
| NHI-03 — Least Privilege and Access Control | Unencrypted credentials increase the blast radius of unauthorized access when they are readable by unintended parties. | |
| Recommendation — Move secrets out of plaintext locations and rotate any secret that may have been exposed. Limit who and what can read secret-bearing data and artifact stores to reduce abuse potential. | ||
| NIST SP 800-63 | AAL — Authenticator Assurance Levels | When plaintext credentials or tokens are exposed, authenticator strength and handling determine how easily access can be abused. |
| Recommendation — Use stronger authenticators and handling practices so exposed secrets do not immediately enable account compromise. | ||
Practitioner Guidance
What to watch for: The highest-value warning signs are plaintext secrets in code, configuration, logs, exports, and pipeline artifacts, plus internal traffic that carries sensitive data without protection. Those are the places where unencrypted data most often turns into a real incident.
Practitioner takeaway: Treat “unencrypted” as a risk signal about both content and context, because the same byte sequence can be low impact in one place and highly exploitable in another.
Related resources from NHI Mgmt Group
- Why does unencrypted data in transit increase breach and compliance risk?
- Why do unencrypted requests and weak transport controls create such a large data security risk for web applications?
- What happens when sensitive data is discovered to be unencrypted in production?
- Why is it important to integrate identity and data governance?
