EP 69 – Cloudy with a 100% Chance of Secrets: Decoding Secrets Management in the Cloud

David Puner: [00:00:00] You’re listening to the Trust Issues podcast. I’m David Puner, a Senior Editorial Manager at CyberArk, the global leader in identity security.
Hello, and happy New Year—which is still maybe okay to say for another minute or two. And if you’re tuning in sometime down the road, happy whatever and congratulations on the thing.
In today’s episode, we take a dive into secrets management and the complexities and considerations involved in securing sensitive information. We do that with Ritesh Desai, General Manager at AWS Secrets Manager, who discusses the evolving landscape of secrets management and the importance of a multi-layered defense strategy.
As organizations continue to adopt cloud services, digital transformation, and agile development practices, the number of secrets—such as API keys, database credentials, and tokens—has grown significantly. Simply securing these secrets is no longer sufficient. Instead, safeguarding sensitive information requires a comprehensive approach that includes discovery, visibility, and leak detection.
In our conversation, Ritesh emphasizes the critical role of machine identities in managing secrets. These identities are key to authenticating and securing automated processes, yet they also pose a significant vulnerability for organizations—especially as multi-cloud environments and AI adoption continue to grow. Machine identities exist in massive numbers and are increasing exponentially.
Among other things, Ritesh highlights the role of AI and automation in enhancing security measures, helping organizations detect and respond to threats more effectively. He also explains how a defense-in-depth strategy can help organizations manage secrets more securely and reduce cyber risks.
He dishes on secrets, as it were.
Happy middle of January! Here’s my conversation with Ritesh Desai.
David Puner: [00:01:50] Ritesh Desai, General Manager at AWS Secrets Manager—welcome to Trust Issues! Thanks for coming on the podcast.
Ritesh Desai: Yeah, thank you, David. I’m excited to be on this podcast.
David Puner: And where are you today? Are you in the Pacific Northwest?
Ritesh Desai: Yeah, I’m in the Pacific Northwest. I’m in Seattle—a suburb of Seattle called Kirkland. That’s where I live.
David Puner: Okay, very nice. At this point, we’re recording in mid-December. Do you have winter at all there? What are things like outside?
Ritesh Desai: Well, Seattle is more rainy than anything. It’s rainy and cold—so no snow, but yeah, it’s cold. It’s about 45 degrees outside, I think.
David Puner: Okay. And you’ve got no rust on the cars out there—I love that! All the great Bring a Trailer cars are always from the Pacific Northwest. I gotta get out there. I gotta visit you sometime.
Ritesh Desai: Yeah, I know.
David Puner: Well, thank you for coming on the podcast. As much as I wish we could talk about cars, rust, and weather, we’re here to discuss some other very important things—though, I guess somewhat tangentially related since they’re cloud-related.
This conversation is focusing on secrets management, and different listeners will have varying levels of understanding. So, why don’t we start things off with this:
What is secrets management, and how do different types of organizations—along with roles or departments within those organizations—think about it?
Ritesh Desai: When I think about secrets, I define them as what your customers use to protect their sensitive information—or to access their sensitive information.
And secrets management is managing the lifecycle of these secrets. It’s critical for the security posture of customers, ensuring they have the ability to meet their organization’s security and compliance expectations.
So, that’s it in a nutshell—what secrets management is.
David Puner: Secrets are things like passwords or API keys, right?
Ritesh Desai: Yeah, absolutely. I was going to go there!
For example—database usernames and passwords, API keys, tokens—anything that you, as a user or a machine, use to access something. That’s a secret.
Secrets management includes the concept of a lifecycle. I think of it in multiple phases:
1. Secure storage – Safely storing the secret.
2. Access control – Providing the right level of access to the right customers.
3. Distribution at scale – Secrets need to reach the right places so applications can run and businesses can operate.
All of those steps are crucial to secrets management.
David Puner: And at scale—because there are just an enormous number of identities and secrets to manage, right?
Ritesh Desai: Absolutely. I’d like to add a couple of things.
One aspect of secrets management that doesn’t get talked about as much is rotation—the regular rotation of secrets is critical to maintaining a strong security posture.
Another key aspect is transparency—customers need visibility through auditing and monitoring to track secrets usage.
So, when you think about it, the full lifecycle of a secret includes:
1. Secure storage
2. Appropriate access control
3. Scalability and distribution
4. Regular rotation
5. Monitoring and auditing
David Puner: Right. And regarding different types of organizations—how do various industries, departments, or roles within organizations approach secrets management?
Ritesh Desai: Traditionally, each department had a specific role.
There was usually a dedicated security team that focused only on security, while development teams focused on building applications. The problem with this segmented approach is that it creates silos, and security becomes an afterthought rather than a built-in function.
At AWS, we encourage organizations to shift their mindset—security should be everyone’s job. It’s not just something for the security team to handle at the end of the development process. Instead, it should be integrated into every step of the workflow—a concept often referred to as “secure by design.”
Yes, some organizations still have dedicated security admins whose primary job is to enforce security standards. But instead of relying only on security teams, we want every department to incorporate security best practices into their work from the ground up.
David Puner: So, rather than relying on a single team to enforce security, the goal is to embed security into the organization’s DNA.
Ritesh Desai: Exactly. If security is integrated from the beginning, then the security team’s role shifts from enforcement to verification—ensuring compliance rather than constantly trying to fix security gaps after the fact.
David Puner: And in terms of industries, are certain sectors more advanced when it comes to secrets management?
Ritesh Desai: Yes. Traditionally, industries like finance, healthcare, and defense have led the way in pushing the boundaries of security.
The good news is that because these industries demanded higher security standards, companies like AWS have built advanced security tools and services to meet those high expectations.
The result? These advancements are now available to all industries—meaning every organization can benefit from best-in-class security solutions, not just the ones in traditionally high-security sectors.
Over time, other industries have recognized the need to elevate their security standards, and we’re seeing a broader adoption of secrets management best practices across different sectors.
David Puner: Of all the different kinds of secrets, what is the most difficult secret to manage? Is there any one particular type that stands out?
Ritesh Desai: That’s an interesting question. I’d actually answer it a little differently.
For a secrets management tool to be truly successful, the less information it has about the secrets it stores, the better—from a security perspective.
That’s why AWS Secrets Manager was designed with this philosophy in mind:
* We don’t need to know what a secret is used for.
* We don’t want visibility into whether a secret is for logging into Google, an admin account, or something else entirely.
Because we don’t store or analyze the contents of secrets, we can apply consistent security policies across all types of secrets—ensuring that every secret is treated with the same high level of security.
David Puner: So, there’s no distinction like, Oh, this is just a password, so we don’t have to worry about it as much? Everything is secured at the same level?
Ritesh Desai: Exactly. It all comes down to access control.
We focus on:
* Enforcing proper access policies
* Providing the right level of protection
* Ensuring that only authorized users or systems can access secrets
At AWS, we follow the Shared Responsibility Model—meaning we give customers the tools to implement strong security controls while ensuring they have the guidance to use them correctly.
But ultimately, it’s up to customers to implement best practices—we can’t make those security decisions for them.
David Puner: Right. Because if AWS were to categorize secrets or assign different security levels, you might make assumptions that don’t necessarily align with how a customer actually uses their secrets.
Ritesh Desai: Exactly. We could easily be wrong in our assumptions, and that wouldn’t help customers at all.
Instead, we provide:
* Robust security mechanisms
* Granular access controls
* Detailed documentation
This allows customers to set their own policies and determine what level of protection each secret requires—based on their unique security and compliance needs.
David Puner: Okay, great. So that’s a solid foundation for understanding what secrets management is. Now, let’s take a step back for a moment to get a better idea of what you do.
What does your day-to-day role as the General Manager of AWS Secrets Manager involve?
Ritesh Desai: Yeah… well, sometimes I don’t even know what I do! But let’s try to break it down.
For anyone in a similar leadership role in secrets management, there are two primary areas of focus:
1. Tactical Execution – Making sure we’re executing on our roadmap and hitting our strategic goals.
2. Strategic Vision – Looking beyond the immediate roadmap to anticipate future needs and industry trends.
Tactically, a big part of my role involves:
* Executing on pre-planned initiatives
* Reassessing priorities based on new data
* Gathering customer feedback
* Monitoring industry trends
At AWS, we have weekly and monthly engineering business reviews where we:
* Evaluate our priorities
* Identify potential course corrections
* Ensure that we’re always moving in the right direction
That accounts for about 30% of my time—along with the usual management and leadership responsibilities.
But the majority of my time is spent on the strategic side:
* Anticipating what’s next in security and secrets management
* Identifying major industry shifts
* Engaging with customer conversations and internal teams to help shape the next big innovations
For example, we look at trends like post-quantum cryptography (PQC) and ask:
* How will this impact our customers?
* What tools will they need to stay ahead of the curve?
* How can we make their transition as seamless as possible?
So, in short, I spend most of my time trying to future-proof our security strategies and ensure we’re delivering the right solutions for our customers—both today and tomorrow.
David Puner: You mentioned generative AI earlier, and I want to talk about that a little later in our conversation. But first, let’s focus on data protection and privacy.
How do data protection and privacy figure into secrets management? I think we’ve touched on this a little bit, but let’s dive deeper. How does it fit into your focus in your role?
Ritesh Desai: Absolutely. Data protection and privacy are always top of mind.
At AWS Secrets Manager, our core mission is to protect secrets that, in turn, protect our customers’ most sensitive data. That means we are constantly working to adhere to the highest level of encryption standards available—and we continue to enhance those standards over time.
For example, in the last four years alone, we’ve upgraded our encryption model three times—each time making it stronger and more resilient.
David Puner: And how do varying regulations factor into that? Different countries, industries, and states all have different privacy requirements, right?
Ritesh Desai: Exactly. That’s one of the biggest challenges in data protection and privacy.
There are many overlapping regulations that customers need to comply with, and they vary by region and industry. Some examples:
* China has a unique data privacy law that differs significantly from other global standards.
* The European Union has GDPR, which came into effect in 2018 and has strict data protection requirements.
* The United States has varying state-level regulations, such as California’s CCPA.
For AWS, our goal is to build tools that give customers control over their compliance requirements—without forcing a one-size-fits-all approach.
Balancing Security and Access
When it comes to privacy, it’s a delicate balance:
* Security is important—but if nobody can access data, then it’s useless.
* On the other hand, if access is too open, it creates serious security risks.
That’s why we focus on least-privilege access—ensuring that users and applications only get access to the specific data they need to do their job.
At AWS, we integrate AWS Identity and Access Management (IAM) with Secrets Manager to enable:
* Role-based access controls
* Granular permission settings
* Resource-based policies
This ensures that only authorized users can retrieve and use secrets—helping to minimize risk while maintaining efficiency.
David Puner: In addition to access control, compliance is another major factor in data protection. How does AWS Secrets Manager help customers stay compliant with all these regulations?
Ritesh Desai: That’s a great question. Compliance is a huge challenge—especially for enterprise customers that operate across multiple regions and industries.
At AWS, we provide a suite of tools to help customers monitor and enforce compliance within their environments. Some of these tools include:
1. AWS Config – Allows customers to set compliance policies (e.g., “All secrets must be rotated every 30 days”).
2. AWS Security Hub – Provides real-time security insights and compliance reports.
3. AWS Secrets Manager Integrations – Works with other security tools to automatically enforce best practices.
For example, let’s say a company mandates that all secrets must be rotated every 30 days. With AWS Config, they can:
* Apply this rule across all accounts and services.
* Automatically identify violations.
* Receive alerts and take corrective actions.
By integrating Secrets Manager with these tools, customers can actively enforce compliance rather than relying on manual oversight.
David Puner: That makes sense. But with so many different regulations out there, is it even possible to automate compliance across the board?
Ritesh Desai: That’s a big challenge.
Each law has multiple clauses that may apply to one use case but not another. The sheer complexity of these regulations makes fully automated compliance nearly impossible.
That’s why our approach is to:
1. Provide customers with the right tools to configure compliance for their specific needs.
2. Work closely with customers to ensure they understand how to set up compliance policies effectively.
This is where partnerships between AWS and customers are so important. Compliance is not just a one-time task—it’s an ongoing process that requires regular updates and adjustments as regulations evolve.
David Puner: Yeah, there are definitely a lot of layers to compliance. Early on in your response, you mentioned encryption. Let’s talk more about that.
Encryption is always evolving—standards keep getting higher and higher. When a new standard of encryption is introduced, how do you determine how long it will remain effective?
Is there a rule of thumb for how long encryption will be top-tier before it needs to be replaced?
Ritesh Desai: That’s a really interesting question.
At AWS, we take a proactive approach to encryption standards. We work closely with global standards organizations to ensure that:
1. We’re ahead of the curve before new encryption standards are released.
2. We help shape those standards based on real-world use cases.
For example, AWS cryptographic teams work with standards committees to validate and refine encryption algorithms before they even become public.
By the time a new standard is formally announced, we’re already:
* Evaluating how to integrate it into AWS services.
* Assessing how customers will transition to it.
* Developing a phased rollout strategy.
Balancing Security and Business Continuity
One of the biggest challenges with encryption is that upgrading encryption isn’t always seamless.
For example, let’s say a company encrypts an entire database using a specific encryption key. If that key needs to be replaced, the transition can be:
* Time-consuming
* Resource-intensive
* Potentially disruptive to business operations
That’s why, in some cases, we strategically delay transitions—not because we don’t want the latest encryption, but because we need to ensure that customers can adopt it without business disruptions.
In short, while we always look ahead to the next level of encryption, we also balance innovation with practicality—making sure customers can transition smoothly and securely.
David Puner: That makes a lot of sense. Now, let’s shift gears a bit.
What are some of the primary challenges when it comes to secrets management in multi-cloud environments?
Ritesh Desai: Ah, one of my favorite topics!
The biggest challenge in multi-cloud environments is centralizing secrets management.
Think about it—if a company has:
* Some workloads running in AWS
* Some workloads running in Azure
* Some workloads running on-prem
Where should they store and manage all their secrets?
The Problem with a Fragmented Approach
One common (but flawed) approach is to:
* Store AWS-related secrets in AWS Secrets Manager
* Store Azure-related secrets in Azure Key Vault
* Store on-prem secrets in a separate vault
But this creates major problems because:
* There’s no single pane of glass to monitor secrets.
* Secrets become scattered across multiple environments.
* Security teams struggle to enforce consistent policies.
How to Centralize Secrets Management in Multi-Cloud
Organizations have two main options:
1. Use an external secrets management tool
* Many organizations choose tools like CyberArk to centrally manage and distribute secrets across cloud environments.
* AWS integrates with CyberArk, so customers can sync their secrets between CyberArk and AWS Secrets Manager.
* This allows customers to leverage AWS-native integrations while still maintaining CyberArk as their single source of truth.
2. Use AWS IAM Roles Anywhere
* AWS offers IAM Roles Anywhere, which allows customers to:
* Obtain temporary security credentials for on-prem, hybrid, and multi-cloud workloads.
* Use AWS services for identity and secrets management, even when workloads are running outside AWS.
Why This Matters
With multi-cloud adoption increasing, more companies are realizing that:
* Managing secrets in a decentralized way is risky.
* Standardizing secrets management is essential.
* Integrating AWS Secrets Manager with CyberArk (or another secrets management tool) helps enforce security and compliance across multiple cloud providers.
David Puner: That makes a lot of sense. And when you layer regulatory compliance on top of multi-cloud environments, I imagine things get even more complicated?
Ritesh Desai: Absolutely. The moment you operate across multiple cloud providers, you’re now dealing with:
* Different access control models
* Inconsistent security policies
* Potential regulatory conflicts
That’s why organizations need a clear strategy for centralizing secrets—without sacrificing flexibility or security.
David Puner: Another major challenge in security is machine identities. How do you think about secrets management in the context of machine identities?
And what are some best practices for securing machine identities at scale?
Ritesh Desai: This is an important topic. The last report I read said that machine identities outnumber human identities by a factor of 45 to 1—maybe even more.
David Puner: Yeah, I’ve seen similar numbers. And machine identities are growing something like three times faster than human identities.
Ritesh Desai: Exactly. And that’s what makes securing machine identities such a unique challenge.
What Are Machine Identities?
A machine identity is essentially a credential that a machine uses to authenticate and access a resource or service.
For example, if an automated process needs to:
* Connect to a database
* Access an API
* Authenticate with another service
It will use a machine identity—which is typically stored as a secret (like an API key, token, or certificate).
The challenge is that traditional security solutions were designed for human identities, not machines.
Why Traditional Security Methods Don’t Work for Machine Identities
For human identities, we’ve largely solved the security problem using Multi-Factor Authentication (MFA).
But with machine identities, we can’t just enable MFA—it doesn’t work the same way.
So, how do we secure machine identities?
Best Practices for Securing Machine Identities
1. Use Short-Lived Secrets
* Instead of long-lived credentials, machine identities should use ephemeral secrets—credentials that automatically expire after a short period.
* This reduces the risk of secrets being stolen and misused.
2. Adopt Just-in-Time (JIT) Access
* Machine identities should only have access when they need it—not all the time.
* Just-in-Time access ensures that credentials are only valid for a specific operation or timeframe.
3. Leverage SPIFFE and SPIRE Frameworks
* Frameworks like SPIFFE and SPIRE allow organizations to create secure identity-based authentication for machines—without relying on static secrets.
4. Automate Secret Rotation
* If you must use longer-lived secrets, they should be automatically rotated on a frequent basis.
* AWS Secrets Manager provides built-in automation for secret rotation.
5. Implement a Zero-Trust Strategy
* Never assume a machine identity is legitimate. Always verify before granting access.
* The Zero Trust model enforces continuous authentication and authorization checks.
Why This Matters
Machine identities are one of the fastest-growing security challenges—and attackers are increasingly targeting them.
By implementing short-lived secrets, automation, and Zero Trust principles, organizations can reduce risk and improve security posture.
David Puner: That makes a lot of sense. And I think it’s important to emphasize that organizations must protect secrets assigned to non-human identities—otherwise, attackers can use them as a way to gain unauthorized access.
Ritesh Desai: Absolutely. And one of the best things organizations can do today is to start automating secret rotation for machine identities.
If a secret is short-lived and rotated frequently, the window of opportunity for an attacker is drastically reduced.
David Puner: We’ve covered a lot of foundational security practices. Now, let’s bring AI and machine learning into the conversation.
How are AI, generative AI, and machine learning being used to enhance secrets management security measures?
Ritesh Desai: AI and machine learning (ML) are already playing a significant role in security—and they’re only going to become more critical.
At AWS, we think about AI/ML in security in three primary ways:
1. Preventing Security Mistakes at the Development Stage
A big security risk comes from secrets being embedded in code or mismanaged during development.
AI/ML tools can help developers write more secure code by:
* Detecting secrets in source code before deployment.
* Providing real-time security recommendations as developers write code.
* Suggesting best practices for secrets storage and management.
For example, AWS launched Amazon Q Developer, a tool that integrates with IDEs (Integrated Development Environments). If it detects a potential security risk, like a hardcoded secret, it will alert the developer and suggest a secure alternative—helping prevent security issues before they happen.
2. AI-Powered Anomaly Detection for Secrets Access
One of the biggest advantages of AI/ML in security is the ability to analyze massive amounts of data and detect suspicious activity in real time.
For example, AI can:
* Monitor access patterns for secrets.
* Identify unusual spikes in access requests.
* Alert security teams to potential breaches.
A practical example—if a secret is normally accessed 10 times per day, but suddenly it’s accessed 10,000 times in an hour, AI can:
* Recognize this as abnormal activity.
* Trigger an alert.
* Potentially block access until further investigation.
This proactive approach allows organizations to detect and mitigate threats before they escalate.
3. Proactive Security and Automated Response
The ultimate goal of AI/ML in security is automated threat response.
Right now, AI can:
* Identify threats.
* Send alerts.
* Recommend security actions.
But in the future, we expect AI to take action automatically, such as:
* Revoking compromised secrets in real-time.
* Blocking suspicious access attempts.
* Rotating secrets preemptively when AI detects potential risks.
For example, in Distributed Denial-of-Service (DDoS) attacks, AI can already:
* Identify malicious traffic patterns.
* Block traffic from suspicious sources—without human intervention.
We expect this same level of automation to apply to secrets management and identity security in the near future.
The Future of AI in Secrets Management
Right now, AI/ML is great at detecting and alerting—but we’re moving toward a future where AI will be able to automatically resolve security risks in real-time.
David Puner: That’s exciting—and also a little scary.
Ritesh Desai: Yeah, it can be! But security is an ongoing journey. AI/ML isn’t about replacing human decision-making—it’s about enhancing security teams by:
* Reducing false positives.
* Providing better insights.
* Taking care of routine security tasks so humans can focus on bigger-picture threats.
We’re already seeing strong adoption of AI-powered security tools, and I expect this to accelerate significantly over the next few years.
David Puner: You’ve mentioned AI and automation as key trends shaping the future of security. Let’s zoom out a bit—since we’re at the start of 2025, what are the biggest trends and innovations in cloud security that will impact secrets management this year?
Ritesh Desai: Great question. I think 2025 is going to be a big year for security, and there are a few major trends that will shape secrets management in the coming months.
1. Increased Adoption of Zero Trust Architecture
The move toward Zero Trust is already happening, but in 2025, we expect to see:
* More organizations shifting to “never trust, always verify” security models.
* Secrets being more tightly controlled and accessed on a least-privilege basis.
* Stronger verification measures for both human and machine identities.
Organizations are realizing that traditional perimeter-based security models no longer work—especially in multi-cloud environments.
At AWS, we’re working with customers to help them implement Zero Trust strategies that ensure:
* Every secret request is verified in real time.
* Secrets are only accessible when absolutely needed.
* Automated policies revoke access immediately when necessary.
2. AI and Machine Learning for Threat Detection
We touched on this earlier, but AI-powered security is going to play a much bigger role in 2025.
We expect to see:
* More advanced AI models for detecting abnormal access patterns.
* Better predictive analytics for identifying potential security threats before they happen.
* Automated secret rotation and access revocation triggered by AI-driven insights.
Right now, AI is helping security teams work faster—but the next step is for AI to start handling real-time security actions automatically.
3. Stricter Data Privacy Regulations
Regulations around data security and compliance are getting tighter every year.
Some key developments in 2025 include:
* New data residency laws requiring organizations to store secrets in specific geographic regions.
* Stronger encryption standards being mandated in multiple industries.
* More regulatory scrutiny on how organizations manage and secure secrets.
Because AWS operates in a global environment, we’re working hard to:
* Stay ahead of these evolving regulations.
* Ensure our customers can maintain compliance across multiple jurisdictions.
* Offer tools that help organizations adapt to new legal requirements quickly.
4. Post-Quantum Cryptography (PQC) Preparation
This might not be a 2025 reality—but it’s a 2025 focus.
Quantum computing poses a potential long-term threat to current encryption methods. Even though large-scale quantum attacks are still years away, security leaders are already:
* Evaluating post-quantum encryption standards.
* Identifying which secrets need future-proof protection.
* Developing strategies for migrating to quantum-resistant algorithms.
At AWS, we’re:
* Actively testing post-quantum encryption methods.
* Working with standards organizations to define the future of encryption.
* Helping customers understand how they can prepare for quantum security challenges.
The Bottom Line
2025 is going to be a big year for cloud security, automation, and compliance. Secrets management is at the center of these trends, and organizations will need to:
* Implement Zero Trust strategies.
* Leverage AI-powered security.
* Ensure compliance with new data privacy laws.
* Start thinking about quantum security—even if it feels a bit early.
David Puner: That’s a great roadmap for what’s ahead. Let’s talk a little more about post-quantum cryptography.
How is AWS thinking about post-quantum encryption, and what should companies be doing today to prepare for future security challenges?
Ritesh Desai: Yeah, this is something I get asked about a lot.
The reality is that full-scale quantum computers capable of breaking today’s encryption are not here yet. But that doesn’t mean we should wait to prepare.
One of the biggest concerns in the industry is the idea of harvest now, decrypt later attacks.
What Is a “Harvest Now, Decrypt Later” Attack?
* Bad actors are already stealing encrypted data today—even though they can’t decrypt it yet.
* They store this data for years or decades until quantum computers become powerful enough to break the encryption.
* Once quantum decryption is possible, previously stolen data could suddenly become accessible.
That’s why companies need to start preparing now—even if quantum threats are still years away.
How AWS Is Preparing for Post-Quantum Encryption
At AWS, we’re taking a multi-layered approach:
1. Inventorying existing encryption systems – Identifying which types of encrypted data need the strongest long-term protection.
2. Testing new post-quantum encryption algorithms – Working with global standards bodies to develop and validate quantum-resistant encryption techniques.
3. Helping customers transition smoothly – Developing strategies for migrating to post-quantum security standards without disruption.
Right now, most organizations should be:
* Taking stock of their encrypted data.
* Identifying long-term sensitive secrets.
* Following developments in post-quantum encryption.
The shift to quantum-resistant encryption isn’t happening overnight—but organizations that start planning now will be in a much stronger position when the time comes.
David Puner: It’s fascinating to think that securing data today is also about protecting it from future threats—even threats that might not materialize for another decade or more.
It sounds like AWS is already well ahead in preparing for post-quantum security. But when it comes to real-world implementation, how do you balance security advancements with the practicality of transitioning customers to new encryption standards?
Ritesh Desai: That’s a great question. At AWS, we take a phased approach to transitioning customers to new security standards.
Here’s how we think about it:
Step 1: Assessing the Impact of New Encryption Standards
* Not all data is equally sensitive or equally at risk.
* We first identify which types of secrets need quantum-resistant protection.
* We work with customers to prioritize what needs to be transitioned first.
Step 2: Testing and Validating New Encryption Methods
* Before rolling out new encryption standards, we test them extensively to ensure:
* They don’t degrade performance.
* They work across different AWS services.
* They provide strong security without breaking existing workflows.
* This is crucial because forcing encryption changes too quickly can actually introduce security gaps if companies aren’t prepared.
Step 3: Implementing a Smooth Transition Strategy
* Rather than making an immediate switch, we give customers time to migrate.
* We provide:
* Clear documentation and best practices.
* Automated tools to make the transition easier.
* Support for hybrid environments—so customers can use both traditional encryption and post-quantum encryption during the transition period.
Step 4: Continuous Monitoring and Improvement
* Security is not a one-time fix.
* Even after adopting new encryption, we:
* Continuously monitor for potential vulnerabilities.
* Optimize encryption performance.
* Refine best practices based on real-world usage.
David Puner: So it’s not just about introducing stronger encryption—it’s about ensuring that customers can adopt it without disruption?
Ritesh Desai: Exactly. Security only works if it’s practical.
That’s why we take an incremental approach—so companies can strengthen their security posture without impacting business continuity.
David Puner: Makes sense. And it ties back to something you said earlier: security is a journey, not a destination.
Ritesh Desai: Absolutely. And that’s what makes secrets management such a fascinating and ever-evolving field.
David Puner: You’ve covered a ton of important topics today. From secrets management best practices to multi-cloud security to AI-powered threat detection and post-quantum encryption.
Before we wrap up, I want to ask—what advice would you give to organizations that are just starting to build out their secrets management strategy?
Ritesh Desai: Great question! If I had to summarize it in a few key takeaways, I’d say:
1. Make security a shared responsibility – Secrets management isn’t just for security teams. It should be built into every part of the organization—from development to operations to compliance.
2. Centralize secrets management – Avoid storing secrets in scattered locations. Use a dedicated secrets management tool to maintain visibility and control.
3. Use automation wherever possible – Rotate secrets automatically. Monitor access patterns with AI. The more you can automate, the stronger your security posture will be.
4. Implement Zero Trust principles – Never assume trust. Always verify. This is especially important for machine identities, where static credentials create risk.
5. Stay ahead of emerging security threats – The threat landscape is constantly evolving. Organizations should be thinking about post-quantum encryption today, even if they won’t need it for years.
David Puner: That’s a fantastic summary. I really appreciate your time today, Ritesh. This has been a great conversation.
Ritesh Desai: Thanks, David. I really enjoyed it!
David Puner: And thanks to everyone for tuning in to Trust Issues!
If you enjoyed this episode, be sure to check out our back catalog for more conversations with cybersecurity experts.
And don’t forget to follow us wherever you get your podcasts—so you never miss an episode.
Oh, and if you have any questions, comments, or suggestions, feel free to reach out! Our email is [email protected].
See you next time!