Skip to main content
NEW · Blast Radius: a field playbook for leaked API keys on AWS, GCP and Azure
← Resources

Practical checklist · NHI security

NHI Security Maturity Checklist: Five Evidence Checks

When you say your API keys and service accounts are managed, what can you show? Answer five questions with records you can inspect.

Cremit6 min read

Start with evidence, not a score

Answer yes, partly, or no for each question. Record where the supporting evidence lives and who owns it. If you cannot find the record, do not mark yes. Handle exposed credentials that need immediate attention first, then expand coverage to missing systems.

These five checks are Cremit’s practical review sequence. They are not a NIST five-level maturity model or a certification standard.

What to record for each credential

Credential type · issuer · consuming service · owner · discovery location · last verified time · response status · recheck record. Never copy the secret value into the checklist.

Five evidence checks

01—05
01

Where is it, and who owns it?

Can you identify the issuer, consuming service, and owner of each credential, and confirm that the record is current?

Evidence to inspect
Compare keys at the issuer with findings from code and connected tools, plus owner assignments.
If it is missing
Start with critical issuers; assign unowned credentials to a responsible team.

Where Cremit helps: Inventory findings from connected scan sources and track owners and status. It does not discover every key in every system.

02

Have you checked exposure paths?

Have you checked repositories, connected collaboration tools, and monitored external assets for visible keys?

Evidence to inspect
Keep the scanned source, scope, time, finding location, and excluded sources.
If it is missing
Connect missing sources. Review discovered external assets and exclude those outside your scope.

Where Cremit helps: Show findings from connected internal sources and external scanning enabled for your organization. A completed scan does not prove that no secret exists elsewhere.

03

Is it valid, and what can it access?

Can you distinguish a working exposed credential from an unverified one and inspect its permissions where supported?

Evidence to inspect
Review the verification status and time for supported types, and permission analysis for AWS access keys or GCP API keys.
If it is missing
For unsupported or uncertain results, ask the issuer administrator to verify manually.

Where Cremit helps: Verify supported credential types and analyze permissions for AWS access keys and GCP API keys. This does not establish whether a key was abused or every resource it can reach.

04

Who rotates or revokes it at the issuer?

After finding the affected services and owner, is there a plan to rotate or revoke the key at its issuer?

Evidence to inspect
Keep the incident owner, rotation or revocation record at the issuer, and service health check.
If it is missing
Check service dependencies and agree on the order of new-key deployment and old-key revocation.

Where Cremit helps: Track findings and incident status. It does not rotate, revoke, or delete keys on your behalf.

05

Did you verify the fix?

Can you show that the old key is no longer valid and that the same exposure path is clear?

Evidence to inspect
Keep issuer status, verification time, rescan result, and reason for closing the incident.
If it is missing
Rescan the same repository and deployment path; put unresolved scope on the next review schedule.

Where Cremit helps: Reverify supported types and rescan connected sources. It cannot certify systems outside the collected scope.

Example: an AWS access key found on GitHub

This is an illustrative workflow, not a customer incident. Do not paste the key value into a page or document.

  1. 01

    Record the discovery location and time; identify the key owner and consuming service.

  2. 02

    Review supported validity checks and AWS permission analysis. A valid key alone does not prove use or compromise.

  3. 03

    The owner deploys a replacement and revokes the old key at the issuer. Adjust the order for service dependencies.

  4. 04

    Check the issuer state and rescan result. Keep unresolved scope in the incident record.

Cremit helps with discovery, verification, permission analysis, and tracking. The responsible team rotates or revokes the key at its issuer.

Basis and sources

OWASP covers secret storage, rotation, revocation, and audit. NIST CSF 2.0 provides a broader risk management framework. The five questions and product examples above are Cremit’s editorial guidance, not maturity levels issued by either organization.