Understanding Credential Severity
Not all credential exposures carry the same risk. A leaked read-only API key for a public service is very different from an exposed database password with admin privileges. Understanding how to assess and prioritize credential severity is critical for effective security operations.
The Severity Framework
Credential severity is determined by evaluating multiple factors together. No single factor tells the whole story—context matters.
Factor 1: Access Level
What can someone do with this credential?
| Access Level | Description | Examples |
|---|---|---|
| Admin/Root | Full control over systems or data | AWS root keys, database admin passwords |
| Write | Can modify data or configurations | API keys with write permissions, service accounts |
| Read | Can view but not modify | Read-only API tokens, viewer accounts |
| Limited | Restricted to specific functions | Scoped tokens, single-purpose keys |
Factor 2: Scope of Impact
How much of your infrastructure could be affected?
- Organization-wide — Credentials that provide access across multiple systems
- Service-specific — Access limited to a single application or service
- Environment-specific — Limited to dev, staging, or production
- Resource-specific — Access to a single database, bucket, or endpoint
Factor 3: Data Sensitivity
What data could be accessed or compromised?
- PII/PHI — Personal or health information with regulatory implications
- Financial — Payment data, banking credentials, financial records
- Business Critical — Trade secrets, strategic plans, customer data
- Internal — Employee information, internal communications
- Public — Already publicly available information
Factor 4: Credential Freshness
Is this credential still valid and in use?
- Active — Currently valid and providing access
- Recently Rotated — Was valid recently, may still work in some systems
- Expired — No longer valid but indicates security practices
- Unknown — Validity cannot be determined without testing
Severity Classifications
Based on these factors, credentials typically fall into four severity levels:
🔴 Critical
Credentials that could lead to immediate, severe impact if exploited.
Characteristics:
- Admin or root-level access
- Organization-wide or production scope
- Access to sensitive data (PII, financial, business critical)
- Currently active
Examples:
- AWS root account credentials
- Production database admin passwords
- Payment processor API keys with full access
- Cloud provider service account keys with owner permissions
Response: Immediate rotation required. Investigate for potential compromise.
🟠 High
Credentials with significant potential for damage but with some limiting factors.
Characteristics:
- Write access to important systems
- Service or environment-specific scope
- Access to internal or business data
- Active or recently active
Examples:
- CI/CD pipeline tokens
- Application database credentials
- Third-party integration keys with write access
- Service account credentials for critical applications
Response: Rotate within 24 hours. Review access logs for suspicious activity.
🟡 Medium
Credentials that pose moderate risk, typically limited in scope or access level.
Characteristics:
- Read-only or limited write access
- Single service or resource scope
- Access to non-sensitive data
- May or may not be active
Examples:
- Read-only API keys
- Development environment credentials
- Monitoring service tokens
- Public API keys with rate limits
Response: Rotate within one week. Add to credential rotation schedule.
🟢 Low
Credentials with minimal risk due to limited access or public nature.
Characteristics:
- Highly restricted access
- Public or non-sensitive data only
- Often already public by design
- Limited blast radius
Examples:
- Public API keys (Google Maps, weather services)
- Read-only tokens for public data
- Expired credentials from decommissioned systems
- Test/demo account credentials
Response: Rotate during normal maintenance. Document for awareness.
Context Changes Everything
The same type of credential can have different severity levels depending on context:
| Credential Type | Low Severity Context | Critical Severity Context |
|---|---|---|
| Database password | Local dev database with test data | Production database with customer PII |
| AWS access key | Read-only access to public S3 bucket | Admin access to production account |
| API token | Rate-limited public API | Payment processing with full access |
| SSH key | Jump host with MFA required | Direct root access to production servers |
Prioritization in Practice
When multiple credentials are exposed, prioritize based on:
- Active + Critical — Handle immediately
- Active + High — Handle within hours
- Unknown + Critical — Verify and handle quickly
- Active + Medium — Schedule for prompt rotation
- Expired + Any — Lower priority but still document
Remember: attackers prioritize the same way. They'll test critical credentials first.
Key Takeaways
- Severity depends on access level, scope, data sensitivity, and freshness
- Context matters—the same credential type can be critical or low risk
- Prioritize response based on combined severity factors
- When in doubt, treat as higher severity until verified otherwise
Proper severity assessment ensures your team focuses energy where it matters most.