A Guide to AWS Secrets Manager for EU Compliance

Think of your application's database credentials and API keys as the master keys to your business. Hardcoding them directly into your source code is the digital equivalent of leaving these keys under the doormat—a convenient but dangerously outdated practice. AWS Secrets Manager is the secure digital vault built to fix this, protecting credentials, managing their lifecycle, and replacing vulnerable static secrets with dynamically-retrieved ones.

What Is AWS Secrets Manager and Why Is It Essential?

Imagine a developer hardcodes a database password into a configuration file. That file is then committed to a code repository, creating a permanent security flaw. If that repository is ever compromised, attackers gain a direct line to your most sensitive data. This common but high-risk habit is precisely the problem AWS Secrets Manager was designed to solve.

Instead of embedding secrets in plaintext, your application makes a simple API call to AWS Secrets Manager to retrieve the credentials it needs at runtime. This small change fundamentally shifts your security posture from reactive to proactive.

A Digital Safety Deposit Box

The best analogy for AWS Secrets Manager is a high-security bank vault.

• Hardcoding Secrets: This is like leaving your valuables out in the open. It's easy, but it relies on nobody looking where they shouldn't.
• Using Secrets Manager: This is like storing your valuables in a secure vault. You don’t carry them with you; instead, you go to the bank, prove your identity, and are granted temporary, audited access. Secrets Manager works the same way—it validates your application’s identity before handing over the credentials.

The diagram below from AWS illustrates this core concept of replacing hardcoded secrets with secure API calls.

This visual highlights the central function of the service: your applications and services fetch secrets programmatically when they need them, rather than storing them locally. This simple shift is the cornerstone of a modern, secure development workflow.

To give you a clearer picture, here is a quick summary of what the service offers.

Core Capabilities of AWS Secrets Manager at a Glance

This table summarises the fundamental features of AWS Secrets Manager, providing a quick reference for its key benefits and functions in a modern security workflow.

Capability	Description	Primary Benefit
Secure Storage and Encryption	Stores secrets (like API keys and database credentials) encrypted by default using AWS KMS.	Protects secrets at rest, preventing plaintext exposure in code or on disk.
Fine-Grained Access Control	Uses AWS IAM policies to control which users and applications can access specific secrets.	Enforces the principle of least privilege, ensuring only authorised entities can retrieve credentials.
Automated Secret Rotation	Natively integrates with AWS services (like RDS and Redshift) to automate password rotation on a schedule.	Reduces the risk of compromised credentials by ensuring they are short-lived and changed regularly without manual intervention.
Auditing and Monitoring	Integrates with AWS CloudTrail and CloudWatch to log and monitor all API calls made to Secrets Manager.	Provides a clear, auditable trail of who accessed which secret and when, which is critical for compliance and incident response.

These capabilities work together to create a robust system for managing one of the most common sources of security vulnerabilities.

A Foundation for Modern Security and Compliance

Adopting a service like AWS Secrets Manager isn't just about better security hygiene; it's a critical step toward meeting stringent regulatory requirements. For instance, the EU's Cyber Resilience Act (CRA) mandates that digital products are designed with security from the start.

Centralising and automating credential management is a core tenet of building a secure-by-design system. By removing secrets from code and logs, you provide clear, auditable evidence that you are taking proactive steps to protect sensitive data and minimise your attack surface.

This makes AWS Secrets Manager an essential tool for any organisation aiming for CRA compliance. It provides the mechanisms to enforce and prove that you have robust controls in place for one of the most common sources of data breaches. If you are preparing for these new rules, understanding how to build a secure software development life cycle is a great place to start.

Automating Security with Core Features

Storing secrets securely is just the starting point. The real power of AWS Secrets Manager lies in its ability to automate the entire secret lifecycle. This automation minimises human intervention, which dramatically reduces the risk of credentials being compromised.

This process flow shows how code should interact with a secure vault like AWS Secrets Manager to feed credentials to an application, completely getting rid of hardcoded secrets.

The critical takeaway here is the separation of concerns. The application code never touches the secret itself—it only holds a reference to it. This completely decouples your application from its sensitive credentials, making your security management far more robust and flexible.

Automated Secrets Rotation

Static, long-lived passwords are a huge security liability. A core feature of AWS Secrets Manager is its built-in capability to automate credential rotation, which directly addresses the best practice of regularly changing your passwords and other sensitive keys. This ensures that even if a secret is somehow exposed, its useful lifetime is extremely short.

For native AWS services like Amazon RDS, Amazon Redshift, and Amazon DocumentDB, rotation is a turn-key function. You can configure Secrets Manager to change a database password every 30 days, for instance, with zero application downtime or manual work.

When a rotation is triggered, Secrets Manager first creates a new ‘pending’ version of the secret. It only promotes this new version to ‘current’ after it successfully verifies that the new password works on the target service. This two-phase process is crucial, as it prevents a failed rotation from locking your applications out.

But what about services without native support, like a third-party API or an on-premises database? Here, you can write a custom AWS Lambda function containing the specific logic needed to update the credential on that external service. Secrets Manager then invokes this Lambda on your defined schedule, giving you a powerful and extensible rotation engine for virtually any secret you can think of.

Fine-Grained Access Control with IAM

Not every application should see every secret. AWS Secrets Manager integrates deeply with AWS Identity and Access Management (IAM) to enforce the principle of least privilege. This ensures that any given application or user can only retrieve the specific secrets they absolutely need to function.

This is all done through carefully crafted IAM policies. You can write policies that grant permission to retrieve a secret based on its name, its tags, or the identity of the user or role making the request.

For example, you could create a policy that only allows a specific EC2 instance role to access database credentials that have been tagged with "Production." A policy to achieve this would look something like this:

{
  "Effect": "Allow",
  "Action": "secretsmanager:GetSecretValue",
  "Resource": "arn:aws:secretsmanager:eu-west-1:123456789012:secret:prod/webapp/database-1a2b3c",
  "Condition": {
    "StringEquals": {
      "aws:ResourceTag/Environment": "Production"
    }
  }
}

This policy grants access to a very specific secret, but only if that secret carries the tag "Environment" with the value "Production." This is how you ensure access remains tightly controlled and auditable, even within a trusted AWS account.

End-to-End Encryption with AWS KMS

Finally, to guarantee confidentiality, every secret stored in AWS Secrets Manager is encrypted by default. This protection is applied both at rest (when the secret is stored) and in transit (when it's requested by your application). The service uses AWS Key Management Service (KMS) to manage the underlying encryption keys.

You have two main options for handling encryption:

• AWS Managed Keys: These are default keys managed by AWS on your behalf. They provide a simple, no-cost way to ensure your secrets are always encrypted.
• Customer Managed Keys (CMKs): For organisations needing more control and auditability, you can create and manage your own encryption keys in KMS. This lets you control the key's rotation policy and define exactly who can use it, adding another powerful layer of security and separation of duties.

By using CMKs, you can ensure that only principals with explicit permission to use your specific key are able to decrypt the secret's value. This combination of IAM policies and KMS encryption creates a formidable defence, making AWS Secrets Manager a cornerstone of any secure cloud infrastructure.

Right, so you've got your secrets neatly stored and rotating. That's a huge win, but the real test is how smoothly AWS Secrets Manager fits into your everyday work. This is where we move from theory to practice, leaving behind risky habits like hardcoding credentials or, even worse, tracking them in spreadsheets.

Bringing Secrets Manager into your workflows is about making secure credential handling an automated, invisible part of your operations. It’s not just another tool; it’s a fundamental shift in how you build and deploy software.

Let's dig into two powerful integration patterns: one for your CI/CD pipelines and another for Internet of Things (IoT) devices. These examples show how to turn secrets management from an afterthought into a core, automated discipline.

Securely Automating Your CI/CD Pipeline

A CI/CD pipeline is the engine of modern software delivery, but it's also a classic security weak point. Pipelines need access to sensitive credentials—database passwords, API keys, you name it—to build, test, and deploy applications. Storing these as plain-text environment variables in your CI/CD tool is a disaster waiting to happen.

Integrating AWS Secrets Manager completely sidesteps this problem. Instead of storing secrets in the pipeline, you allow the pipeline to fetch them on-demand, just in time for when they're needed. The secrets never live in your configuration.

Here’s how it works in practice with a tool like GitLab or Jenkins.

A Step-by-Step CI/CD Integration Example

Let's say your pipeline needs to run database migrations during a deployment. Forget storing the database password as a masked variable. Instead, you grant the CI/CD runner temporary, highly-restricted permissions to pull it directly from AWS Secrets Manager.

1. Create a Dedicated IAM Role: First, you create an IAM role just for your CI/CD pipeline. The policy attached to this role should be incredibly strict, only allowing the secretsmanager:GetSecretValue action on the exact secret it needs (e.g., arn:aws:secretsmanager:eu-central-1:123456789012:secret:prod/database/password-AbCdEf). Nothing more.

2. Configure the Runner: Your CI/CD runner, whether it's on an EC2 instance or running in a Kubernetes pod, is set up to assume this IAM role. This gives it the temporary credentials required to talk to AWS services securely.

3. Fetch the Secret in the Pipeline Script: Inside your deployment script (like a .gitlab-ci.yml or Jenkinsfile), you add a command to fetch the secret using the AWS CLI. It's a simple, powerful line.

   export DB_PASSWORD=$(aws secretsmanager get-secret-value --secret-id prod/database/password --query SecretString --output text | jq -r .password)
   

4. Use and Unset the Secret: The script now has the password available in a short-lived environment variable (DB_PASSWORD). It uses this to connect to the database and run the migrations. As a final, crucial step, the script should unset the variable to ensure the credential vanishes once its job is done.

This approach pulls the secret completely out of your source code and CI/CD configuration. Access is temporary, tightly governed by IAM, and every single request is auditable in CloudTrail. Each time the pipeline runs, it gets a fresh copy of the credential, guaranteeing it always has the latest version, even right after a rotation.

While this example used a database password, the exact same pattern works for any credential your pipeline needs. Properly securing automation secrets is a critical practice, and you can learn more about it in our guide to managing secrets in GitLab CI.

Credentialing IoT Devices at Scale

IoT and connected hardware present a unique security headache. How do you securely get credentials onto thousands, or even millions, of devices out in the field? You can't hardcode a single shared secret—if one device is compromised, your entire fleet is exposed. This is a massive concern under regulations like the EU Cyber Resilience Act, which mandates secure-by-design principles.

AWS Secrets Manager, paired with AWS IoT Core, offers a scalable and elegant solution. The strategy is built around devices using temporary, short-lived credentials to fetch their own unique, long-term secrets when they first boot up.

The IoT Bootstrapping Pattern:

• Initial Identity: Each device is manufactured with a unique X.509 certificate. This certificate acts as its unchangeable birth identity, used to authenticate with AWS IoT Core.
• Requesting Temporary Credentials: When a device connects, it presents its certificate to the AWS IoT Credentials Provider to assume a very limited IAM role. This role grants it temporary, time-bound permissions to call AWS Secrets Manager.
• Fetching Long-Term Secrets: Armed with these temporary credentials, the device makes a direct API call to AWS Secrets Manager to retrieve its operational secrets. This could be anything from a Wi-Fi password or an MQTT broker address to an application-specific API key.

This pattern is incredibly robust. The high-value operational secrets are never stored in the device's firmware. All the device holds is its initial identity certificate. If a device is ever stolen or tampered with, its temporary credentials expire in minutes, and you can revoke its access centrally by disabling its certificate in AWS IoT Core. This approach ensures your IoT fleet is built on a security foundation strong enough to meet the high standards of modern connected products.

Achieving Compliance with the EU Cyber Resilience Act

For any organisation with digital products in the European Union, the upcoming Cyber Resilience Act (CRA) is a major regulatory shift. It mandates that products with digital elements are secure by design and throughout their entire lifecycle. To meet these new obligations, AWS Secrets Manager is an essential tool, providing the technical controls needed to prove your product is secure and compliant.

The CRA demands a fundamental move toward proactive security, leaving reactive fixes behind. This is where centralised, automated secrets management becomes not just a best practice, but a core compliance requirement.

Fulfilling Secure-by-Default Requirements

Annex I of the CRA lays out the essential security requirements, starting with a core principle: products must be delivered with a secure-by-default configuration. This means minimising the attack surface from the moment a customer unboxes or installs your product. Hardcoding credentials directly into your application code is a clear violation of this principle.

AWS Secrets Manager helps you meet this requirement by design. By pulling secrets out of your codebase and configuration files, you eliminate one of the most common and dangerous sources of vulnerabilities. Instead of shipping products with static, embedded credentials, your applications fetch them dynamically at runtime.

This approach ensures:

• No Embedded Secrets: Credentials are never part of your software package, source code repository, or container images.
• Least Privilege Access: Through IAM policies, you can grant an application permission to retrieve only the exact secrets it needs, and absolutely nothing more.
• Reduced Attack Surface: Since secrets aren't stored on disk or held in memory for long periods, the window of opportunity for an attacker is dramatically smaller.

This documented separation of secrets from code provides powerful, concrete evidence for your technical documentation and conformity assessment, demonstrating a deliberate and robust security architecture.

Demonstrating Vulnerability Handling and Auditing

The CRA places a heavy emphasis on continuous security, including vulnerability management and the ability to push security updates. Automated secret rotation is a powerful mechanism for mitigating the risk of a credential leak, which the regulation treats as a serious vulnerability.

When a credential leak is discovered, the ability to rapidly and automatically rotate the compromised secret across your entire infrastructure is not just a best practice; it's a direct demonstration of effective vulnerability handling as mandated by the CRA.

Every API call to AWS Secrets Manager is logged in AWS CloudTrail. This creates an immutable, auditable record of every access attempt—who or what requested a secret, which secret was requested, and when the request occurred.

This audit trail is indispensable for compliance. It gives you concrete evidence to show regulators and auditors that you have robust controls in place. For a deeper look into this topic, you might be interested in our article on CRA logging and monitoring requirements. This evidence is vital for building your technical file and proving adherence to Annex I.

Streamlining Evidence Collection for Conformity

Proving compliance often means drowning in a mountain of documentation and manual evidence gathering. When you integrate AWS Secrets Manager into a modern DevSecOps workflow, the process becomes far simpler.

Instead of manually compiling spreadsheets of credentials and access policies, you can point directly to your infrastructure's real-world configuration.

Practical Example: Preparing for a CRA Audit

Imagine an auditor asks you to prove how you protect database credentials for your product. Instead of handing over a policy document, you can show them:

1. The IAM Policy: Show the exact, restrictive IAM policy granting your application’s role access to a specific secret in Secrets Manager.
2. The CloudTrail Logs: Export the logs showing that only that designated role has accessed the secret.
3. The Rotation Configuration: Display the AWS Secrets Manager setup that automatically rotates the secret every 30 days.

This automated, configuration-as-code approach delivers undeniable proof of your security controls. It transforms compliance from a paper-chase into a verifiable, engineering-driven discipline, helping you confidently prepare for the EU market.

Understanding Costs and Regional Strategy in the EU

Adopting any new service means looking closely at the price tag, but for businesses in the EU, the real conversation is about strategic value. With AWS Secrets Manager, the pricing is refreshingly simple, but its true worth extends far beyond the monthly invoice, especially when you factor in data residency and compliance with frameworks like GDPR and the Cyber Resilience Act (CRA).

The pricing model for AWS Secrets Manager hinges on two straightforward metrics:

• The number of secrets you store each month.
• The number of API calls made to the service.

This pay-as-you-go approach means you can start small and have your costs scale predictably as you grow. There are no hidden fees or complex licensing to worry about.

Calculating the Total Cost of Ownership

To put this into perspective, let's think about a mid-sized company operating in the EU. Their security team is juggling all sorts of credentials—database passwords, third-party API keys, and tokens for internal services.

Let's run the numbers for a hypothetical company using the service in an EU region.

Example Scenario: A Mid-Sized Company
Imagine this company manages 500 secrets, and its applications make a total of 200,000 API calls per month to fetch them.

• Cost per secret: There's a small fee for each secret stored per month.
• Cost per 10,000 API calls: API requests are billed in blocks of 10,000.

While these direct costs are typically quite low, the real return on investment comes from reducing risk and boosting operational efficiency. By automating secret rotation and centralising management, you dramatically lower the odds of a costly data breach. You also free up valuable engineering time that was once wasted on manual credential updates.

This is where treating your security posture as code becomes a massive advantage. For a deeper look at the tools involved, check out our guide on Terraform vs CloudFormation for CRA compliance.

Regional Strategy for EU Data Residency

For any business operating within the EU, cost is only half the story. Data sovereignty and compliance are non-negotiable. The CRA and GDPR impose strict rules on how sensitive data is handled, which makes your choice of AWS region a critical strategic decision.

By using AWS Secrets Manager within an AWS region located inside the European Union—such as eu-central-1 (Frankfurt), eu-west-1 (Ireland), or eu-south-2 (Spain)—you guarantee that your sensitive credentials never physically leave the EU’s legal jurisdiction.

This regional strategy is not just a technical choice; it is a foundational pillar of your compliance posture. It provides a clear, defensible answer to auditors and regulators asking where your most sensitive secrets are stored and how they are protected, aligning directly with GDPR's data residency principles.

This is absolutely vital for manufacturers and importers who must verify and document CRA conformity for any product with digital elements placed on the European market.

Choosing a local region has a measurable impact. For instance, in the Europe (Spain) region, eu-south-2, AWS Secrets Manager fully supports data residency for CRA compliance needs. A mid-sized user of a platform like Regulus Pro managing around 1,500 secrets might see monthly costs of about $604.50.

Since May 2022, Secrets Manager has published detailed usage metrics to CloudWatch in all regions. This allows teams to monitor usage with precision and align their spending with CRA workflows, which can potentially reduce related consulting costs by 30-50%. You can find more data about AWS Secrets Manager usage across industries on Enlyft.

Of course. Here is the rewritten section, adopting the voice and style of an experienced human expert.

---

Common Questions About AWS Secrets Manager

When you're evaluating a security service like AWS Secrets Manager, a few practical questions always come up. We'll get straight to the point on how it stacks up against alternatives, its use in hybrid environments, and what happens when things go wrong.

How Does It Compare to Parameter Store?

People often ask about the difference between AWS Secrets Manager and AWS Systems Manager Parameter Store. While both can hold sensitive data, they are built for different jobs.

Think of Parameter Store as a general-purpose configuration locker. It's great for storing application settings, feature flags, and other bits of configuration data—some of which might be secrets, like passwords.

AWS Secrets Manager, on the other hand, is a dedicated, high-security vault designed specifically for the full lifecycle of your most sensitive credentials.

Its real power comes from two key features:

• Automated Rotation: It has built-in, out-of-the-box support for automatically rotating credentials for services like Amazon RDS, all without you having to write and maintain custom Lambda functions.
• Secret Generation: It can generate strong, random secrets, such as complex passwords, directly within the service itself.

This focus on automated lifecycle management makes AWS Secrets Manager the clear choice for high-stakes credentials like database passwords and third-party API keys, especially when you're operating in a regulated environment.

Can It Be Used with On-Premises Applications?

Absolutely. You can and should centralise your secrets management with AWS Secrets Manager, even if you run a hybrid environment with on-premises applications. As long as your on-premise application can reach the internet and has the right IAM permissions, it can fetch secrets securely.

A very common pattern is to create a dedicated IAM user with an access key and secret key just for your on-premises application. The application then uses the AWS SDK with these credentials to call the GetSecretValue API, retrieving the secret it needs at runtime.

For example, a Python application running on a server in your local data center could use the boto3 library to fetch a database password like this:

import boto3
import json

client = boto3.client(
    'secretsmanager',
    region_name='eu-central-1',
    aws_access_key_id=ON_PREM_ACCESS_KEY,
    aws_secret_access_key=ON_PREM_SECRET_KEY
)

response = client.get_secret_value(SecretId='prod/onprem/database_password')
secret = json.loads(response['SecretString'])
db_password = secret['password']

This approach gives you a single source of truth for secrets across your entire infrastructure, both in the cloud and on-premises.

What Happens if My Secret Rotation Fails?

This is a critical question, and AWS Secrets Manager has a built-in safety net to prevent a failed rotation from causing an application outage. The entire process is designed to be fault-tolerant.

When a rotation starts, Secrets Manager first creates a new, 'pending' version of the secret with the new password. The rotation Lambda function then connects to the actual service (like your database) and updates the password there. Only after the function confirms the update was successful does Secrets Manager promote the 'pending' version to become the 'current' one.

If any part of this process fails—for example, if the database is unreachable or the new password doesn't meet complexity rules—the rotation is aborted. The 'pending' version is simply discarded, and the old 'current' version remains active and untouched.

This design ensures a failed rotation never locks your application out. For added peace of mind, you can configure Amazon CloudWatch alarms to notify your team immediately if a rotation ever fails, so you can investigate without any disruption.

---

Regulus is the leading compliance platform designed to help manufacturers and software developers prepare for the EU's Cyber Resilience Act. We provide a clear, step-by-step roadmap to assess your products, generate required documentation, and manage vulnerabilities—all without costly consulting. Gain clarity and confidence for your EU market strategy by visiting https://goregulus.com.