Secure by Design – Part 4

Why Secrets Are Not an Infrastructure Problem

When discussing the security of modern platforms, the topic of secrets inevitably arises sooner or later. API tokens, database passwords, SSH keys, certificates, cloud credentials, or service accounts form the foundation of nearly every infrastructure. Without them, systems cannot be operated or automated.

Despite their central importance, secrets are still primarily viewed as a technical detail in many organizations. They are seen as a necessary prerequisite for automation, as operational parameters, or as components of individual applications.

This is precisely where the problem lies.

Because secrets are not an infrastructure component.

They are trust relationships.

And thus, they are among the most critical elements of modern platform architectures.

The Silent Spread of Privileged Access

A similar pattern can be observed in almost every company.

Initially, there are only a few credentials used by a manageable number of systems. However, with increasing automation, the number of identities grows continuously. New applications require API keys, CI/CD pipelines need access to Container Registries, Terraform requires permissions within the cloud platform, and [Kubernetes] workloads communicate with databases or external services.

With each new level of automation, additional trust relationships are established.

The real issue is not the number of secrets.

The problem is that organizations often have insufficient insight into where these secrets are actually used.

A single cloud credential can appear simultaneously in multiple repositories, build systems, runtime environments, and automation processes. An SSH key can be distributed across dozens of systems for years. An API token can be long forgotten yet still provide productive access.

The complexity does not arise from the existence of individual credentials.

It arises from their distribution.

Why Classic Secret Management Strategies Often Fall Short

Most companies have recognized the fundamental problem. Accordingly, vault solutions are introduced, secrets are stored encrypted, and sensitive data is removed from source code repositories.

These measures are undoubtedly sensible.

However, they often only solve part of the problem.

Because the real security question is not:

“Where is a secret stored?”

The real question is:

“What are the implications of a compromise of this secret?”

This perspective fundamentally changes the consideration.

A securely stored access key remains highly critical if it grants an automation platform extensive permissions within a cloud environment. Similarly, an encrypted token remains problematic if its usage is not traceable or its scope remains unknown.

The storage of a secret is merely one aspect of its lifecycle.

The real challenge is to make its usage controllable.

The Problem of Static Trust Relationships

This issue becomes particularly evident with long-term valid credentials.

Many platforms still rely on static secrets that are used unchanged for months or years. Service accounts receive extensive permissions, API tokens are permanently stored, and SSH keys remain within productive environments for long periods.

From the perspective of operations teams, this approach often seems pragmatic.

From the perspective of security architecture, however, it poses a significant risk.

Every long-term trust relationship increases the period during which a compromise can potentially be exploited.

An attacker does not necessarily have to compromise production systems.

Often, access to a single identity with sufficiently extensive permissions is enough.

The real question, therefore, is not whether credentials are protected.

The question is whether their existence is necessary at all in the long term.

The Shift from Secrets to Identities

Modern security architectures are increasingly moving away from the classic management of static credentials.

Instead, the identity itself is becoming the focus.

Cloud platforms have been pursuing this approach for several years. Short-lived tokens replace long-term credentials. Workloads authenticate through defined trust models. Machines receive temporary permissions that automatically expire.

The reason for this development is obvious.

While a static secret must be protected over a long period, a short-lived identity significantly reduces the attack surface. Even in the event of a compromise, the window for abuse remains limited.

The architecture thus shifts from managing sensitive information to managing trust relationships.

This is a fundamental difference.

Because identities can be controlled, monitored, and time-limited.

Static secrets, on the other hand, remain merely digital keys that must be permanently protected.

Why Platforms Can Multiply Secrets

Interestingly, a significant portion of modern risks does not arise within productive systems but within the platforms that manage these systems.

Automation platforms typically require access to a variety of different environments. They communicate with cloud providers, [Kubernetes] clusters, databases, monitoring systems, registries, and other infrastructure components.

As a result, significant amounts of privileged access accumulate in a central location.

The platform itself thus becomes a concentration point of trust.

This development is not necessarily problematic.

However, it requires a shift in thinking.

The central question is no longer how individual secrets can be secured.

The central question is how the platform that uses these secrets is controlled.

This shift is one of the most important developments in modern security architectures.

Why Traceability Becomes More Important Than Encryption

Encryption is often considered the ultimate security measure in dealing with secrets.

In reality, however, encryption only solves a very specific problem.

It protects data during storage.

However, it does not answer the question of who has used this data.

For the security of a platform, this question is often significantly more relevant.

When privileged access has been used, security officers want to know which systems were affected, what actions were taken, and under what conditions access occurred.

The ability to answer these questions often determines whether a security incident can be analyzed quickly or whether extensive forensic investigations are necessary.

Traceability is therefore not a compliance requirement.

It is a security mechanism.

Secure by Design Begins with Trust

The discussion about secrets is often reduced to technical details. Encryption algorithms, secret stores, or rotation intervals dominate many architectural discussions.

In doing so, it is easily overlooked that it is not really about credentials.

It is about trust.

Every secret represents a trust relationship between systems. Every identity defines what actions are possible within a platform. Every permission expands the scope of action for a user, a service, or an automation.

Secure by Design therefore does not mean protecting as many secrets as possible.

Secure by Design means consciously modeling, controlling, and continuously questioning trust.

The more platforms grow, the more important this ability becomes.

Because modern infrastructures are not primarily held together by servers, Containers, or networks.

They are held together by trust relationships.

And it is precisely there that it is ultimately decided how secure a platform really is.

In the next part of this series, we will address a topic closely related to trust and control, yet surprisingly receives little attention in many organizations: the question of why governance in modern platform architectures should not be understood as an organizational discipline, but as a technical property of the platform itself.