The first time Anupam Nandan, CISSP, attempted to automate large-scale service account password rotation, he disrupted a production system that supported real-time business operations. It wasn’t catastrophic, but it was serious enough to stop everything. Here’s what he learned.
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
I’d always approached secrets management - the practice of safely storing, using and tracking digital credentials like passwords, API keys and database tokens - largely as a tooling problem. My hypothesis felt logical: choose the right vault, integrate applications, automate rotation and security will improve. To my surprise, the issue that arose was far more problematic than the tool, the script, or even the rotation logic. It forced me to pause and rethink everything I believed about secrets management.
That was because what we uncovered was no technical failure, but a systemic one. Secrets were everywhere across the enterprise: embedded in applications, pipelines, scripts and infrastructure. But no one had a complete understanding of where they existed, how they were being used, or who truly owned them.
Visibility Before Control
One of my earliest realizations – and, honestly, one that caught me off guard – was how little visibility existed, despite having multiple “enterprise-grade” tools in place. We were already doing many of the right things: we had vaults, integrations and monitoring. But, when we started digging deeper, the reality looked very different.
Secrets were scattered across environments, cloud platforms, on-prem systems, DevOps pipelines and even local configuration files. Different teams had adopted different solutions over time, each solving their own immediate need. Collectively, this had created fragmentation. There was no single inventory, no consistent classification or, more importantly, clear ownership model.
We were trying to control something we didn’t fully understand. Before enforcing policies or scaling automation, we needed to ask – and answer – some fundamental questions, including:
- Where do secrets exist?
- How are they used?
- Who owns them?
- What risk do they represent?
Only after building that visibility would control start to make sense.
Automation Amplifies Weaknesses
If I had to identify one moment that genuinely changed my approach, it was when we acknowledged that automation exposes problems, not fixes them.
Because, going into the program, I was optimistic about automation; like many architects, I believed that automating credential rotation at scale would immediately reduce risk and improve efficiency. Instead, it revealed everything that was broken.
To my surprise, we uncovered instances of undocumented dependencies between applications, shared service accounts being used across multiple systems and fragile integrations that no one had fully mapped. When rotation happened, these hidden connections surfaced – often in the form of outages or failures.
It was an inevitable turning point for me; automation is not, by itself, a solution, but it is a multiplier. That is to say: if the underlying process is weak, automation will amplify that weakness. My perspective shifted from “How do we automate faster?” to “What process are we actually automating and is it mature enough?”
We slowed down, redesigned workflows, introduced ownership, dependency mapping, phased rollouts and proper exception handling. Only then did automation start working for us instead of against us.
Centralization Isn’t the Same as Control
Initially, my strong belief was that consolidation was the answer. It felt intuitive to bring everything into a single vault, standardize the approach and simplify the architecture.
In practice, it didn’t work that way. Large enterprises are inherently complex: different teams operate in different environments with different constraints. When we tried to ‘force’ everything into one platform, it created friction and resistance. So, instead of pushing for strict consolidation, we moved toward a federated model. We centralized governance, policies and visibility, but allowed execution to remain distributed.
It transpired that this was a far more practical and scalable approach, respecting the realities of the organization while still enforcing consistency. Our goal was no longer to force everything into one system, but evolved into ensuring that everything operated under one control model.
Secrets Management Is Really an Identity Problem
This important realization reshaped how I now think about the future of security. At the beginning of the journey, secrets felt like a technical domain, owned by infrastructure or security engineering teams. But as I spent more time in the environment, I started to see a different pattern.
Secrets are not just credentials. They enable access for non-human identities, service accounts, APIs, workloads and automation processes. These identities operate continuously, often without direct human oversight. Again, to my surprise, the scale of this was far greater than I initially expected.
Secrets management must not just be about securing credentials, but about controlling how non-human identities authenticate and operate across an enterprise. For me, this realization connected secret management to a broader ecosystem identity governance, privileged access management and zero trust. Secrets are not a side problem, but part of the core identity layer.
The Real Problem Is the Operating Model
I’d thought – wrongly – that deploying the right tools would solve these issues. Looking back now, it’s obvious that the most important factor wasn’t technical at all, but organizational. Across the enterprise, I observed the same patterns: siloed ownership, inconsistent policies, fragmented processes and limited accountability. Different teams approached secrets management in different ways, often without alignment. The real challenge was, in fact, the operating model.
What we needed was clear governance, defined ownership, standardized lifecycle processes, continuous monitoring and, most importantly, alignment across teams. Once we had put those elements into place, everything else – the tools, automation and integrations – started to fall into place.
Secrets aren’t just “credentials sitting in a vault”. They’re the control layer for how modern enterprises operate, especially as non-human identities and autonomous systems continue to grow. Managing them effectively is no longer optional. So, if there’s one important thing this experience taught me and that I’d like to share with others, it’s that secrets management is about discipline, not just tools. I’m talking about discipline in understanding where secrets exist, in defining ownership, and in managing the lifecycle consistently across a complex environment.
In summary – and we should hardly be surprised, given the wider meaning of “secret” – discipline is foundational to secrets management!
Anupam Nandan, CISSP, has over 18 years of experience across healthcare, financial services, retail, energy and technology sectors. He has held technical and leadership roles, with responsibility for enterprise cybersecurity architecture, privileged access management, and zero trust transformation initiatives. His cybersecurity work spans secrets management, non-human identity security, cloud transformation and large-scale enterprise security modernization.
