Enforcing Security Contacts Across AWS Accounts

When AWS discusses the concept of security maturity, one of the easiest and most effective quick wins they recommend is making sure that every account within your organization has the appropriate Security Contact properly configured. While this might initially seem like a minor or routine housekeeping task, it is, in reality, a crucial step that plays a significant role in incident response, regulatory compliance, and overall governance. Ensuring the right contact information is set up correctly can greatly improve communication during security incidents, help meet compliance requirements, and strengthen the governance framework of your cloud environment.

In this post, I’ll take the time to explain in detail why Security Contacts matter and the crucial role they play in maintaining the security of your AWS environment. After that, I will guide you step-by-step through a CloudFormation stack that you can easily deploy to automatically enforce Security Contacts consistently across all of your AWS accounts, ensuring a more secure and well-managed infrastructure.

Why Security Contacts Matter
Within every AWS account there are three types of alternate contacts:

• Billing
• Operations
• Security

The Security Contact is used by AWS in several circumstances:

• They detect suspicious activity in your account (compromise alerts, abuse reports, etc.)
• Urgent security advisories need to be communicated
• Compliance or regulatory notifications are required

If you do not have this contact properly configured—or if it is set to direct notifications to a personal inbox instead of a monitored team address—your security team might miss critical, time-sensitive alerts that require immediate attention. In some cases, when these alerts go unactioned for a significant period, AWS may take preventive measures such as freezing your account and suspending associated services. This can lead to unexpected downtime for your applications, causing disruptions to your business operations and potentially impacting your customers.

In multi-account environments (especially those using AWS Organizations or Control Tower), management of this risk is magnified. Without automation or policy enforcement, it’s too easy for new accounts to be created without a proper Security Contact set.

Centralizing Security Contacts in AWS Organizations
Good news though! AWS provides APIs and CloudFormation hooks that let you set and enforce Security Contacts centrally. The solution below:

• Applies your designated Security Contact email/phone/title across all accounts in your AWS Organization
• Automatically applies the contact when new accounts are created via AWS Organizations or Control Tower
• Optionally deploys an SCP (Service Control Policy) to prevent anyone from removing or overriding the contact.

CloudFormation Resources
The CloudFormation resources are available at this GitHub Repository [1].

How It Works

• A Lambda function sets the Security alternate contact across all accounts (including the management account).
• EventBridge rules trigger the Lambda whenever a new account is created via:
  • Organizations (CreateAccountResult events)
  • Control Tower (CreateManagedAccount events)
• A daily sweep can re-apply the setting, ensuring no drift.
• An optional SCP prevents unauthorized updates or deletion of the contact. While this is optional, it comes highly recommended… The first thing a threat actor may do once gaining access to your account is remove or change the security contact. Applying this SCP will reduce the risk of this scenario.

Deployment Steps

1. Firstly Enable trusted access from your management account via the AWS CLI or AWS Cloudshell:
   
   aws organizations enable-aws-service-access --service-principal account.amazonaws.com
   
2. Deploy the CFN stack(s) as outlined on the GitHub Readme:
   • ManageSecurityContact.yaml
     • If using Control Tower → deploy in your Control Tower home region
     • If using AWS Organizations (only) → deploy in US-East-1
   • ProtectAlternativeContacts.yaml
     • Deploy to US-East-1
3. Test & Verify
   • Confirm the correct Security Contact details are configured on your Member Accounts
   • Try to adjust the alternative contact within a member account, to confirm this option is now restricted
   • (Optionally) Create a new AWS Member Account and confirm the Security Contact details were correctly set

Closing Thoughts
Security maturity goes far beyond simply having the latest tools and automation in place—it fundamentally revolves around ensuring that all the essential basics are thoroughly covered and well-managed. By consistently enforcing the presence of Security Contacts across every single AWS account, you create a reliable and direct communication channel that guarantees AWS can reach your security team immediately when critical situations arise and timely intervention is required.

References
[1] GitHub Repo. – https://github.com/keithstafford/EnforceAWSSecurityContacts

About
With over 20 years in the technology sector, Keith has spent the last decade providing consultancy, support, and strategic direction to customers across multiple cloud platforms.

Disclaimer: The information shared on this blog is for informational purposes only and should not be considered as professional advice. The opinions presented here are personal and independent of any affiliations with tech companies or organizations.