If a senior engineer left tomorrow, could you list the credentials to rotate in two minutes?
Not the procedure to find the list. The list itself. For most CTOs running production software for more than three years, the honest answer is no. And the reason is architectural, not disciplinary.
A one-hour session with one of our engineers identifies the real credential map of your infrastructure today, the exposure points you could not close on short notice, and the centralization architecture suited to your stack. You receive a written report. It stays yours, regardless of the next step.
One source of truth.
Credentials live in a single encrypted store, separated from operational configuration and read by applications at runtime. Nothing in plaintext, anywhere in the repository.
Rotation in one operation.
Select a perimeter, click rotate. Credentials regenerate centrally, authorised applications receive the new values without anyone touching a file. Confirmation arrives in the security channel.
Audit, fully visible.
Every credential reads with a timestamp, an identity, and a source. When an engineer leaves on Friday, the perimeter to rotate is visible Monday morning before coffee.
The map your company never built.
For most CTOs running software in production for more than three years, the honest answer to the opening question is no.
Not because discipline is missing. Because the story of a growing company is also the story of credentials that stratify in different places, at different times, following logics nobody ever centralised. An API key generated in 2022 for a test integration that became permanent. A database password shared via Slack during a midnight incident, never changed. An admin token inside a .env file that a third of your developers cloned to their personal laptop.
The map of all this exists in no document, because it was never built. You open one vault, check. The credential isn't there. You try another. Not there. You message the internal channel. Five minutes later someone responds with a screenshot of a .env, prefixed PROD_, written two years ago. That is the real map: distributed across laptops, private messages, archived repositories, and the individual memories of the people who work with you.
When one of those people leaves, a portion of the map leaves the company with them.
What changes when the map becomes the system.
Offboarding takes minutes, not days.
The complete list of credentials a departing engineer had access to is visible at a glance, with timestamp of last use. The rotation perimeter is selected and executed in one operation.
Incident rotations stop accumulating debt.
The password shared at midnight during an incident is rotated the same week, automatically. No more credentials living in production for years because nobody remembers where they are.
Audits stop being archaeology.
When auditors ask who accessed what and when, the answer comes from a log, not from interviews. Compliance reviews shift from reconstruction to verification.
Trust scales with the team.
New engineers get access through identity, not through credential sharing. Senior engineers stop being human single points of failure for production knowledge.
The map can become the system.
The configuration that makes this scene possible is a consolidated architectural pattern in cloud-native systems. Centralized secret management separates sensitive data from operational configuration, keeps credentials encrypted at rest, and lets applications read them at runtime rather than have them written inside.
The technology exists. The implementation has three prerequisites. Whether your current infrastructure meets them is the work of one focused session.
The mechanism, in plain terms.
Two architectural paths exist for teams operating in GitOps, where the entire configuration is versioned in Git. Sealed Secrets encrypts the credential with the public key of the target cluster before commit, so the plaintext value never touches the repository. External Secrets Operator, the better fit for mature infrastructures, keeps the source of truth in an external secret manager like HashiCorp Vault or a cloud KMS service, and the cluster synchronises values at runtime without them ever appearing in Git.
Whether either path is viable in your infrastructure depends on three prerequisites.
A single source of truth, declared.
Every credential in production must be traceable to one canonical location. Today this rarely exists by default. Secrets accumulate in vaults, password managers, .env files, and private messages. The first work of the migration is identifying the inventory before centralizing it.
A centralized rotation mechanism, automated.
One operation must regenerate the credential and propagate the new value to every authorised application, without manual intervention. This requires applications that read secrets at runtime, not at build time, and a deployment pipeline that handles the propagation deterministically.
An audit log that survives the question.
Every read of every credential must be recorded with timestamp, identity, and source. The log is the answer to the question that opens this page: it is what makes the credential map visible in real time, instead of reconstructable in hours of investigation.
When the three are aligned, the result is the configuration described above. When one is missing, the assessment identifies which one, and the path to address it.
What this architecture does not solve.
Centralized secret management solves one thing completely: the fragmentation of internal credentials in production, and the ability to answer the opening question in under two minutes. It is worth saying clearly what it does not solve.
- Discipline on external credentials outside your perimeter, the ones your developers use to access third-party services via web dashboard.
- Secrets embedded in code from before the system was introduced, which need to be migrated one at a time.
- An access rights audit, which remains a separate exercise from credential management.
None of these are abstract problems. Each one is a real piece of work with its own scope, methodology, and timeline. The assessment names them when they are present, and indicates which ones to address before or after the centralization effort. The architecture is a foundation. It is not the whole building.
One hour. One engineer. One written report.
A working session, structured around your stack.
One hour with one of our engineers. Remote, scheduled within 72 hours of request. Paid engagement, billed independently of any work that may or may not follow.
The real credential map of your infrastructure today.
Where secrets currently live. Which ones touch production. Which ones cross the boundary into developer laptops. Which ones an offboarding would require rotating, and which ones the team would struggle to find at all.
A written report, with a clear recommendation.
Current inventory of credentials in production. The exposure points you could not close on short notice today. The centralization architecture suited to your stack (Sealed Secrets vs External Secrets Operator). A realistic timeline. The migration approach.
The report belongs to you.
Use it internally, share it with your CISO, share it with another vendor. There is no obligation to proceed with Graftholders. The assessment is paid; the analysis is yours to keep regardless of the next step.
Why this works as a written report.
Most security vendors arrive with a fixed solution and adapt the diagnosis to fit it. Our model is the opposite: the diagnosis is the product. The intervention, if any, follows.
A written report does three things a conversation cannot. It survives the meeting. It can be circulated internally to your CISO, your CTO, your compliance team. People who weren't in the room. And it commits the analysis to writing, which is the only form in which security recommendations can be evaluated rigorously and turned into a roadmap.
The session is paid for a reason: it filters both sides. We commit a focused hour and a written deliverable to every case, which means we only run assessments where the case actually warrants one. In a meaningful portion of them, the conclusion is that the current architecture is the right fit for the stage of the company, and no migration is recommended now. We say so, in writing.
The report is yours. Whether you proceed with Graftholders, with another vendor, or with no vendor at all, the analysis travels with you.
Engagement by stage.
Every engagement starts with the assessment. Everything that follows is optional, activated only when your case requires it.
Assessment
Diagnosis before design. Current credential map, exposure points, and architectural recommendation mapped in a written report. The outcome is a clear recommendation, including the option of not migrating now when that is the right answer.
Migration and Setup
Centralized secret management deployed on your cluster, with the architecture identified in the assessment. Existing credentials migrated in staged batches, applications reconfigured to read at runtime. Fixed-fee delivery, three tiers based on complexity.
Team Enablement
One to two days. Your team learns to operate the system in full independence: how to add credentials, how to rotate, how to audit. On-site or remote. Per-edition pricing, independent of headcount up to a defined cap.
Maintenance Pack
Prepaid days, used on demand. For clients who want ongoing coverage without a monthly retainer. Updates, rotation reviews, periodic exposure scans, spot penetration testing. Packs of 5, 10, or 20 days, twelve-month validity.
Optional
Stack details
Applications installed through GitOps. Standard CNCF and open-source components. No proprietary forks. Configured during cluster setup, declared in version control, deployed and updated through GitOps.
Standard CNCF and open-source components. No proprietary forks. Configured during cluster setup, declared in version control, deployed and updated through GitOps.
Where are you?
2 minutes to understand if Kubernetes makes sense for your case right now.
Four client profiles.
Three project stages.
Different starting points, the same methodology. Select where you are today.
You think Kubernetes is overkill for where you are now?
For early-stage startups that don't yet know what they need, a full Kubernetes cluster can feel out of reach. We build a simple, working prototype that lets you ship and scale without committing to infrastructure you don't need yet. This is one of our most requested services.
Early-stage product in production
Early-stage company with an MVP in production. Limited budget, no dedicated DevOps. Cloud costs already a concern.
Cluster on low-cost European cloud
Production-ready Kubernetes cluster with integrated GitOps pipeline. Optional application development on top of the cluster.
Predictable European infrastructure
Engineering team aligned on the cluster from delivery. Maintenance available on demand if required.
Regulatory or geographic constraints
Data-residency, latency, or sector-specific compliance requirements (healthcare, finance, public sector). Hyperscaler defaults do not fit.
Bare metal cluster, constraint-driven
Kubernetes cluster on European bare metal. Architecture designed around regulatory and geographic constraints. Integrated GitOps pipeline.
Infrastructure built for your constraints
Built for the client's constraints, not for the provider's catalog. Predictable costs.
Established team, stable workload
Significant in-house development team. Stable workload, governance requirements, long-term infrastructure ownership.
Workload-matched architecture
Kubernetes cluster on European bare metal with architecture matched to actual workload patterns. GitOps as operational methodology. Optional retainer.
Governed by your team
Infrastructure governed by the client's team, not by an external vendor. A partner available on demand.
Multi-region complexity
Multi-region operations, varied latency requirements, differing regulatory environments, distributed engineering teams.
Multi-region, compliance integrated
Multi-region Kubernetes architecture on European bare metal. Compliance integrated by design (IEC 62443, CRA, NIS2, GDPR). Cross-region GitOps.
Single point of contact
Compliance built in from day one, not retrofitted. One interlocutor across the full delivery chain.
Your product can't run on Kubernetes as it is?
If your application is not cloud-native and can't be containerized in its current form, we rebuild it. We rewrite the parts that block the migration, keep the business logic intact, and deliver a system that runs on modern infrastructure from day one.
Different profile?
A one-hour assessment defines the case, the constraints, and the right path forward.
Request assessmentThree ways to govern credentials. One that keeps the map yours.
Do it yourself
- You design the architecture from scratch
- Migration of existing credentials is on your team
- Significant in-house security expertise required
- Long time to a verified production state
- Risk of incomplete migration leaving exposure points
- The map remains partially in heads, not in systems
Done for you
- Faster initial setup
- The architecture is the vendor's, not yours
- Migration of legacy secrets is your problem
- Lock-in by design. Your map lives in their cloud
- Limited visibility into the encryption and rotation pipeline
- Audit logs are theirs, with their export limits
Done with you
- Hybrid model: speed of managed, control of in-house
- You stay involved in every architectural decision
- Migration of legacy credentials is part of the engagement
- No vendor lock-in. The architecture is yours
- The map and the audit log live in your perimeter
- Standard open-source tooling, no proprietary fork
Technical capabilities.
Encryption at rest
All credentials encrypted in storage. Plaintext values never touch the repository, never travel in logs.
GitOps-native
Sealed Secrets and External Secrets Operator integrated from day one. Configuration versioned, auditable, reproducible.
One-operation rotation
Select perimeter, click rotate. Credentials regenerate centrally. Authorised applications receive new values at runtime.
Full audit log
Every credential read recorded with timestamp, identity, source. The audit log is yours, in your perimeter.
Provider-agnostic
Works on European bare metal, European cloud, US hyperscalers, or on-premise. The secret store can be Vault, KMS, or cluster-native.
Team ownership transferred
Documentation, runbooks, and operational knowledge delivered with the system. Your team operates it after handover.
Related reading.
Technical articles and scenario analysis on Kubernetes operations and cloud infrastructure.
The phone that no longer vibrates
On the architectural pattern that absorbs the nightly incidents your team currently absorbs in person.
Read the article →The day the funnel worked too well
When your campaign succeeds but the infrastructure wasn't built for the peak. How autoscaling changes that.
Read the article →Every team that ships software
Deployment stops being an event when you adopt blue/green deployment and canary release patterns.
Read the article →Your senior engineer just quit
The architectural pattern for centralized secret management that lets you rotate credentials in one click.
Read the article →The line on the invoice no one can explain
The cost structure of managed services, and how Kubernetes restores forecasting and freedom to choose.
Read the article →The renewal where you hold no cards
How lock-in accumulates through reasonable decisions, and how Kubernetes restores freedom to move.
Read the article →The question in the tender you cannot answer
Data sovereignty beyond location: control over where your production workload runs and who operates it.
Read the article →The environment that lives in two people's heads
When production is reproducible from code, onboarding becomes instant and rebuilding takes hours.
Read the article →Questions, answered directly.
We already use HashiCorp Vault. Is this still relevant?
Often yes. Having Vault deployed and having credentials actually centralised in Vault are different states. The assessment evaluates the real adoption: how much of your production map lives in Vault today, where the gaps are, and what the rotation pipeline looks like end to end.
What if we are not on Kubernetes?
The pattern of centralized secret management exists independently of Kubernetes. The assessment evaluates your current stack and identifies the right substrate for your case. Kubernetes is the most common host today, but it is not a requirement.
How long does the migration typically take?
It depends on the size of the current credential inventory and how distributed it is. Infrastructure setup is typically a few weeks. The migration of existing credentials runs in staged batches over several more weeks to avoid disruption. The exact timeline is in the assessment report.
Does this help with NIS2, CRA, or ISO 27001 compliance?
Centralized secret management is foundational for the access control and audit logging requirements of all three frameworks. It does not constitute compliance by itself, but it removes one of the most common findings in pre-audit gap analyses. The assessment notes which compliance frameworks are in scope for your case.
What does the migration and setup cost?
Fixed fee based on complexity. Three tiers, set by inventory size and architectural maturity. The exact figure is defined after the assessment, based on what we actually find in your infrastructure.
What happens after the setup?
The architecture, the documentation, and the operational knowledge belong to your team. Maintenance is purchased on demand. No monthly retainer, no contractual lock-in.
Is Graftholders limited to credential management?
No. Managed Kubernetes infrastructure, software development, and industrial cybersecurity (IEC 62443, CRA, NIS2, GDPR) are part of the broader offering. Clients engage through the most relevant entry point.
The map can become the system.
One hour with one of our engineers. A written report covering the real credential inventory of your infrastructure today, the exposure points you could not close on short notice, the centralization architecture suited to your stack, and a realistic timeline. The report is yours, regardless of what you decide to do with it.
Request assessment/ Response within 24 hours, with next steps