AWS re:Invent 2025 has arrived, and it's shaping up to be one of the most transformative cloud conferences in Amazon Web Services history. Running from December 1-5 at various venues across the Las Vegas Strip, including the Venetian and Caesars Forum, this year's conference brings together tens of thousands of developers, cloud architects, business leaders, and tech enthusiasts from around the globe.

The theme dominating this year's event is unmistakably Agentic AI – autonomous AI systems that can reason, make decisions, and take action independently. With over 2,300 specialized learning sessions, five major keynotes, and groundbreaking product announcements, AWS is making a bold statement about the future of cloud computing and artificial intelligence.

This comprehensive guide covers all the major announcements and innovations unveiled at re:Invent 2025, organized by category to help you understand how these developments can transform your business.

We've all heard the phrase: "Identity is the new perimeter."

But here's the uncomfortable truth most security teams are missing — the perimeter isn't being breached by compromised employee credentials or phishing attacks. It's being breached by the identities you don't even know exist: Non-Human Identities (NHIs). ( APIs. Service accounts. Machine credentials. Bot tokens. IoT device certificates. Container orchestration keys. )

These digital identities power every modern enterprise. They enable automation, orchestration, and the seamless integration that businesses depend on. But they've also become the fastest-growing attack vector in cybersecurity — and most organizations have zero governance over them.

The numbers are staggering: 70% of security breaches now involve Non-Human Identities.

What Are Non-Human Identities?

Non-Human Identities (NHIs) are digital credentials that allow machines, applications, and automated processes to authenticate and communicate with each other. Unlike human users who log in with usernames and passwords, NHIs operate silently in the background, enabling critical business functions.

Common types of NHIs include:

• API Keys: Credentials that allow applications to access external services
• Service Accounts: Automated accounts used by applications to perform tasks
• Machine Certificates: Digital certificates for server-to-server authentication
• Bot Credentials: Authentication tokens for automated processes and RPA
• IoT Device Tokens: Credentials embedded in connected devices
• Container Secrets: Authentication data used in Kubernetes and Docker environments
• CI/CD Pipeline Tokens: Credentials used in automated deployment processes

The Scale of the Problem

Here's what makes NHI security so challenging:

1. NHIs Outnumber Human Users 10:1

In a typical enterprise environment, Non-Human Identities outnumber human users by a factor of ten or more. A company with 1,000 employees might have 10,000+ machine identities operating across their infrastructure.

Traditional Identity and Access Management (IAM) solutions were never designed to handle this scale.

2. NHIs Have Elevated Privileges

Unlike human users who typically have role-based access, many service accounts and API keys are provisioned with broad, standing privileges. A single compromised service account often has more access than any individual employee — making it the perfect target for attackers seeking lateral movement.

3. NHIs Are Rarely Rotated or Monitored

Human passwords have rotation policies. Human access is reviewed periodically. But NHIs? They're often created once and forgotten.

Our research shows the average NHI credential age exceeds 3 years without rotation. Some organizations have service accounts that haven't been updated in over a decade.

4. NHIs Are Increasingly Targeted by Attackers

Sophisticated threat actors have recognized this vulnerability. Recent attack patterns show a deliberate shift toward targeting machine identities for:

• Persistence: NHIs provide long-term access without triggering user-based security alerts
• Privilege Escalation: Service accounts often have admin-level access
• Lateral Movement: Machine-to-machine trust relationships create pathways across the network
• Data Exfiltration: API keys can provide direct access to sensitive data stores

Real-World Impact: The Cost of NHI Compromise

The consequences of NHI security failures are severe and increasingly common.

Case Study: The Moneyview Breach (October 2025)

On October 27, 2025, Dubai-based attackers exploited compromised API keys to extract approximately $5.8 million USD from Moneyview — a leading Indian fintech platform — in just three hours.

The attack vector? A single Non-Human Identity with access to critical financial systems. No phishing required. No social engineering. Just one ungoverned machine credential.

This isn't an isolated incident. Major breaches at companies across healthcare, finance, and technology sectors have traced back to compromised service accounts and API keys.

The Compliance Dimension

NHI governance isn't just a security concern — it's increasingly a compliance requirement.

ISO 27001

The updated ISO 27001 framework now explicitly addresses machine identity management as part of access control requirements. Organizations pursuing or maintaining certification must demonstrate governance over all identity types.

SOC 2

SOC 2 Type II audits are beginning to include questions about service account lifecycle management, API key rotation policies, and machine identity inventory.

Industry-Specific Regulations

Financial services (PCI-DSS), healthcare (HIPAA), and government contractors (FedRAMP) all have evolving requirements around identity governance that extend to Non-Human Identities.

The compliance gap is real: Organizations that fail to govern NHIs are increasingly finding themselves flagged during audits.

The Three Phases of an NHI Breach

Understanding how attackers exploit Non-Human Identities is crucial for defense. Most NHI breaches follow a predictable pattern:

Phase 1: Discovery

Attackers scan for exposed credentials through:

• Public code repositories (GitHub, GitLab, Bitbucket)
• Misconfigured cloud storage (S3 buckets, Azure blobs)
• Leaked configuration files
• Dark web credential markets
• Social engineering of DevOps teams

Phase 2: Exploitation

Once credentials are obtained, attackers:

• Test API keys for valid access
• Map the scope of service account permissions
• Identify high-value targets accessible through the credential
• Establish persistence mechanisms

Phase 3: Lateral Movement and Exfiltration

With a foothold established, attackers:

• Leverage machine-to-machine trust relationships
• Pivot to additional systems using the compromised identity's access
• Extract sensitive data
• Deploy ransomware or establish long-term presence

Building an NHI Governance Framework

Addressing NHI security requires a comprehensive governance approach. Here's the framework we recommend:

1. Discovery and Inventory

You can't secure what you don't know exists. The first step is comprehensive discovery:

• Scan all repositories for embedded credentials
• Inventory service accounts across cloud and on-premise systems
• Map API integrations and their associated keys
• Identify IoT devices and their authentication mechanisms
• Catalog CI/CD pipeline credentials

2. Classification and Risk Assessment

Not all NHIs carry equal risk. Classify based on:

• Access level: What systems and data can this identity access?
• Business criticality: What processes depend on this identity?
• Exposure risk: Is this credential at risk of exposure?
• Compliance impact: Does this identity touch regulated data?

3. Policy Implementation

Establish clear policies for NHI lifecycle management:

• Provisioning: Least-privilege access by default
• Rotation: Automated credential rotation schedules
• Monitoring: Real-time alerting on anomalous NHI behavior
• Deprovisioning: Clear processes for retiring unused credentials

4. Continuous Monitoring and Audit

NHI governance isn't a one-time project:

• Implement continuous monitoring for credential misuse
• Regular access reviews for service accounts
• Automated alerting for policy violations
• Periodic audits against compliance frameworks

Why Traditional IAM Falls Short

If your organization has invested in Identity and Access Management solutions, you might wonder why NHI security requires special attention.

The reality is that traditional IAM was designed for human users:

• Authentication flows assume interactive login
• Access reviews are built around human managers
• Lifecycle management follows HR processes (onboarding, role changes, offboarding)
• Risk scoring is based on human behavior patterns

NHIs don't fit these models. They don't have managers. They don't change roles. They don't exhibit "normal" behavior patterns. They need purpose-built governance.

Taking Action: Your Next Steps

Addressing NHI security can seem overwhelming, but progress is possible with a structured approach:

Immediate Actions (This Week)

1. Audit your public repositories for exposed credentials
2. Inventory service accounts with admin-level privileges
3. Identify API keys that haven't been rotated in 12+ months

Short-Term Initiatives (This Quarter)

1. Implement secrets management for new projects
2. Establish rotation policies for critical credentials
3. Deploy monitoring for service account activity

Strategic Program (This Year)

1. Build comprehensive NHI inventory across all systems
2. Implement governance framework with clear policies
3. Integrate NHI security into compliance programs

Learn More: Join Our Free Webinar

Want to dive deeper into Non-Human Identity governance?

Codewave and StackGuard are hosting a free educational webinar:

The Silent Majority of Risk: Mastering Non-Human Identity Governance

What You'll Learn:

• The NHI threat landscape with real-world data
• Compliance implications for ISO27001, SOC2, and industry frameworks
• The three phases of an NHI breach and how to defend against each
• A practical governance framework you can implement immediately

Featured Speakers:

• Kapil Jain, CEO — StackGuard
• Ankit Mehta, CEO — Codewave

🎁 Bonus: Attendees get a chance to win an Amazon Gift Card!

When AWS quietly deprecated CodeCommit in July 2024, I'll admit - I wasn't surprised. The writing had been on the wall. GitHub and GitLab had already won the developer mindshare battle, and AWS seemed to be cleaning house under new CEO Matt Garman. CodeCommit was slow, feature-poor, and frankly, felt like an afterthought in AWS's sprawling service catalog.

What I didn't expect was this: AWS just brought it back.

Yesterday, AWS announced CodeCommit's return to full general availability. Not just maintaining it for existing customers, but actively investing in it with Git LFS support coming in Q1 2026 and regional expansions planned. This is remarkable, and it says something important about where cloud computing is heading.

Why This Matters

Here's what AWS learned that we've been telling our clients for years: integration depth matters more than feature richness when you're operating at scale.

CodeCommit never had the slickest UI or the most advanced collaboration features. What it had was something far more valuable for enterprise teams - seamless IAM integration, VPC endpoint support, CloudTrail logging, and native connectivity with CodePipeline and CodeBuild. For teams in regulated industries or those running complex AWS-native architectures, that integration isn't just convenient. It's often the difference between a compliant system and a compliance headache.

When we work with clients on cloud migration and DevOps implementations, we see this pattern constantly. The "best" tool on paper often loses to the one that fits naturally into your existing infrastructure. CodeCommit wasn't competing with GitHub on developer experience. It was solving a different problem - giving AWS-centric teams a repository solution that spoke the same security and governance language as the rest of their stack.

The Broader Signal

This reversal tells us something bigger about the current state of cloud services. AWS listened to their customers and reversed course. In an industry where deprecation announcements usually mean "start planning your exit," this is almost unprecedented.

The feedback AWS received was clear: customers in regulated industries couldn't easily replicate CodeCommit's tight AWS integration with third-party providers. When you're dealing with strict compliance requirements, having your source control behind the same IAM policies and VPC configurations as your compute infrastructure isn't a nice-to-have. It's fundamental architecture.

This is exactly the kind of consideration that should drive your DevOps and DevSecOps strategy. At Codewave, we constantly evaluate whether a service's ecosystem fit outweighs its standalone capabilities. Sometimes the answer is yes - use the integrated AWS service. Sometimes it's no - the specialized third-party tool is worth the integration overhead. But you can't make that call without understanding both your compliance requirements and your operational complexity.

What We're Watching

AWS promised Git LFS support - their most requested feature. That's huge for teams managing design assets, ML models, or any workflow involving large binaries. The regional expansion to eu-south-2 and ca-west-1 also signals they're serious about making this globally viable.

But here's what I'm really watching: whether AWS can move fast enough. The deprecation announcement caused real damage. Teams spent time and resources planning migrations. Some completed them. Trust was broken. AWS acknowledged this and apologized, which is commendable. But rebuilding that trust means consistent investment and clear communication going forward.

For Our Clients

If you're currently using CodeCommit - this is good news. The uncertainty is over, and there's now a roadmap.

If you migrated away - don't feel pressured to migrate back. GitHub, GitLab, and Bitbucket are excellent platforms. The right choice depends on your specific architecture, team preferences, and compliance requirements.

If you're evaluating options - CodeCommit is back on the table, especially if you're heavily invested in AWS services and need that deep integration. But have the conversation about whether that integration is truly valuable for your use case or just convenient.

The Real Lesson

The CodeCommit story isn't really about Git repositories. It's about listening to customers and understanding that in enterprise cloud infrastructure, integration patterns matter as much as features. It's about AWS recognizing that even "small" services can be critical to specific customer segments.

For those of us building and migrating cloud architectures, it's a reminder to look beyond surface-level feature comparisons. The best solution is the one that fits your broader ecosystem, compliance requirements, and operational model - not the one with the most GitHub stars.

AWS brought CodeCommit back because customers made it clear they needed an AWS-native repository solution. That's customer feedback working exactly as it should. Now let's see if AWS can turn this resurrection into something worth keeping alive.

Thoughts on AWS's reversal? Have questions about whether CodeCommit makes sense for your architecture? Let's discuss in the comments or reach out directly - we're always happy to talk through cloud strategy decisions.