Secrets Management Guide

1. Introduction and Scope

1.0 Normative Language (Mandatory Keywords)

The following keywords are used to express requirement strength in this standard:

• SHALL / MUST: Mandatory requirement. Non-compliance requires an approved exception.
• SHOULD: Recommended requirement. If not implemented, rationale should be documented.
• MAY: Optional requirement.
• MUST NOT / SHALL NOT: Prohibited requirement.

1.1 Purpose

The purpose of this standard is to define how the Government of Malawi stores, accesses, rotates, and audits secrets. It applies to all credentials and sensitive configuration used by applications, scripts, automation, and humans to access government systems or data. It does not replace the need for strong authentication (IAM) or for secure key storage in HSMs where PKI or high-assurance use cases require it; it complements those standards by governing the broader set of secrets that are not suitable for hard coding or manual handling.

1.2 Scope of Application

This standard applies to all government ministries and departments; state-owned enterprises and parastatals; local government authorities; and government contractors and consultants when they develop or operate systems that use secrets for government data or services. It covers secrets used in on-premises, government cloud, and vendor-managed environments where the government retains responsibility for how credentials are handled. It applies to both person identities (e.g. service account passwords) and non-person identities (e.g. API keys for integrations).

1.3 Definitions and Key Terms

Secret – any credential or sensitive value that must be protected from unauthorised disclosure. It includes passwords, passphrases, API keys, OAuth tokens, private keys (when not in an HSM), connection strings containing credentials, and similar items. It does not include data that is encrypted and for which the encryption key is already managed under PKI or HSM policy.

Secrets management solution – A dedicated system or service designed to store secrets securely, control access (e.g. by identity and role), support rotation, and produce audit logs. Examples include HashiCorp Vault, cloud provider secrets services (e.g. AWS Secrets Manager, Azure Key Vault), or government-operated equivalents that meet the requirements of this standard.

Rotation – The process of changing a secret (e.g. password, API key) on a schedule or after an event (e.g. compromise, personnel change). Rotation reduces the window of exposure if a secret is later discovered.

Least privilege – Access to secrets is granted only to the identities (human or application) that need them for a defined purpose, and only for the minimum set of secrets required.

2. Core Objectives and Success Metrics

2.1 Primary Objectives

No secrets in code or config – Applications, scripts, and infrastructure-as-code must not contain plain-text secrets. Secrets must be retrieved at runtime from a secrets management solution or from a secure, approved mechanism (e.g. environment variables injected by a secure orchestration layer, not committed to repos).

Centralised or governed storage – All secrets used by government systems must be stored in a centralised secrets management solution (or in a federated set of solutions under central governance). Ad hoc storage in files, spreadsheets, or shared documents is prohibited.

Access control and audit – Access to secrets is restricted by identity and role (integrated with IAM). All access (read, use, rotate) is logged and retained for audit. Unauthorised access attempts are alerted.

Rotation – Secrets are rotated according to policy: passwords and API keys at least annually or more frequently for high-risk use; immediate rotation upon suspected or confirmed compromise or upon personnel separation.

Compliance – Secrets management supports the security and accountability requirements of the Data Protection Act (2024) and the cybersecurity and record-keeping obligations of the Electronic Transactions and Cybersecurity Act (2016).

2.2 Key Performance Indicators (KPIs)

2.3 Minimum Baseline and Prohibitions

• Minimum controls (floor): All secrets used by government systems SHALL be stored in a governed secrets management solution; no plain-text secrets in code, config, or version control. Access to secrets SHALL be restricted by identity and role; all access SHALL be logged and retained per policy. Critical and high-risk secrets SHALL be rotated at least every 90 days; all others at least annually; rotation within 24 hours on compromise. All exceptions SHALL be in the exception register with compensating controls and expiry.
• Prohibitions: MUST NOT store secrets in plain text in code, config files, or version control. MUST NOT grant exception without recording in exception register.

3. Governance and Compliance Framework

3.1 Governance Structure

Document Owner – The Ministry of Information and Communication Technology (MoICT), Department of eGovernment, owns this standard. The Department of eGovernment or designated body governs the selection and operation of the government-wide or federated secrets management solution(s).

System Owner – Accountable for ensuring that systems under their responsibility use secrets in line with this standard.

Security Officer – Validates controls and governs exceptions.

System Administrator or Developer – Implements integration with the secrets solution and ensures that applications and automation do not embed plain-text secrets.

Secrets solution operator (central or ministry) – Operates the solution, defines policies, and supports rotation and audit.

3.2 Compliance Framework

Where secrets management is assessed against external baselines, the following order of precedence applies. The more restrictive requirement applies in case of conflict.

Malawian law. Data Protection Act (2024) for security of processing and breach notification; Electronic Transactions and Cybersecurity Act (2016) for cybersecurity.

NIST SP 800-53 Rev. 5 (e.g. IA-5 for authenticator management, SC-12 for key management, AC-2 for account management) where government systems are categorised under that framework.

NIST SP 800-63B and IAM standards for password and credential lifecycle where secrets are used for authentication.

CIS Benchmarks and DoD STIGs where they address credential storage or configuration (e.g. no credentials in scripts).

Regional. African Union and SADC frameworks; any Malawi-specific or MACRA guidance.

3.3 System Categorisation

Secrets associated with High Impact systems (classified or highly sensitive data) require the strictest controls: shortest rotation interval, strongest access control, and mandatory audit. Medium and Low Impact systems still require centralised storage, no plain-text in code, and rotation per policy; rotation frequency and audit retention may be tiered by risk.

3.4 Safe Exception Process

Exceptions to mandatory secrets management requirements (e.g. legacy system temporarily unable to use the central solution, delayed migration) SHALL be requested, documented, and reviewed as follows. Exception requests must include: system or service name; requirement(s) from which an exception is sought; justification; compensating controls and timeline; proposed end date; and sign-off from System Owner and Security Officer.

• Request: The System Owner submits an exception request (government form or template), stating the requirement(s) from which an exception is sought, justification, and proposed compensating controls.
• Documentation: Each exception SHALL document: justification; compensating controls and timeline for remediation; risk acceptance by the System Owner and validation by the Security Officer; maximum exception duration (not to exceed 12 months unless re-approved).
• Review: Exceptions SHALL be reviewed at least quarterly; extensions require re-approval.
• Register: All exceptions SHALL be recorded in an exception register and made available for audit.

4. Secrets Management Requirements

4.1 Storage

Secrets must be stored only in the designated secrets management solution(s). The solution must protect secrets at rest (e.g. encryption with keys managed separately, ideally in an HSM or key management service) and in transit (TLS). The solution must support access control (integration with government IAM where possible) and must not expose secrets in logs or in responses beyond what is necessary for the authorised consumer. Backup and replication of the secrets store must be encrypted and access-controlled.

4.2 Access Control

Access to read or use a secret is granted only to identities (human or application) that have a justified need. Access is granted by role or policy, not by sharing the secret value. Applications and automation use machine identities (e.g. service accounts, OAuth clients) that are granted the minimum set of secrets required for their function. Access is reviewed at least annually; inappropriate access is revoked. Integration with the Malawi Government IAM Standards ensures that only authorised identities can authenticate to the secrets solution and that deprovisioning in IAM results in loss of access to secrets.

4.3 Rotation

Secrets are rotated on a schedule or on event. Passwords and API keys for High Impact systems are rotated at least every 90 days; for other systems, at least annually. Rotation is performed without requiring application downtime where the solution and application support it (e.g. dual-value rotation). Upon suspected or confirmed compromise, the affected secret is rotated and revoked immediately; related secrets (e.g. same service account elsewhere) are reviewed and rotated if necessary. Upon personnel separation, all secrets to which that person had access are reviewed and rotated where appropriate.

• 4.3.1 Secret Classes and Rotation Matrix (Baseline)
• To make policy enforceable, secrets SHOULD be classified at least as:
• Human credentials (admin accounts, break-glass)
• Machine/application credentials (service accounts, API keys)
• Signing keys / private keys not in HSM
• Database credentials

Ministries SHOULD maintain a rotation matrix by secret class and system tier (Critical/High/Medium/Low), aligned with the KPI targets in this document and any system-specific constraints. Where rotation cannot meet policy, an exception SHALL document compensating controls and an end date.

4.4 Prohibition of Plain-Text Secrets

Secrets must not be stored in source code, configuration files, environment files (e.g. .env committed to version control), infrastructure-as-code files (e.g. Terraform variables with plain-text secrets), wikis, email, or shared documents. Pre-deployment or pre-commit scanning (e.g. secret detection in CI/CD) must be used to prevent accidental commit of secrets; any detection must trigger remediation before merge or release. Historical repos must be scanned and remediated (secrets rotated and removed from history where feasible, or repos taken offline until fixed).

4.5 Audit and Logging

All access to secrets (read, list, rotate, create, delete) is logged with identity, timestamp, and action. Logs are retained for at least 90 days online and in accordance with government records retention for archived logs. Logs are protected from tampering and are available to Security Officers and auditors. Unauthorised or anomalous access (e.g. access outside business hours, bulk access) is alerted for investigation.

5. Integration with Applications, Automation, and CI/CD

5.1 Application Integration

Applications retrieve secrets at runtime from the secrets management solution via a supported API or SDK. Connection to the solution is over TLS; the application uses a machine identity (e.g. certificate, OAuth client credentials stored in a secure bootstrap mechanism) to authenticate to the solution. Applications must not cache secrets in plain text in memory longer than necessary; sensitive memory should be cleared when the secret is no longer needed where the platform permits.

5.2 Infrastructure Automation and CI/CD

Pipelines and infrastructure-as-code (e.g. Terraform, Ansible) must not contain plain-text secrets. They obtain secrets from the secrets solution at pipeline runtime (e.g. via a secure plugin or injected environment). Deployment and orchestration systems (e.g. Kubernetes) use native secrets objects or integration with the central solution; secrets are not baked into images or configs in plain text. The Malawi Government Infrastructure Automation and CI/CD Standards reference this standard for credential handling.

5.3 Human Access

Where humans need to retrieve a secret (e.g. for initial setup or break-glass), access is via the secrets solution UI or CLI, with authentication (MFA per IAM) and audit. Secrets are not sent by email or stored in documents. Temporary access may be granted with expiry.

6. Incident and Compromise Response

6.1 Suspected or Confirmed Compromise

If a secret is suspected or confirmed compromised (e.g. leaked in a repo, phished, or exposed in a breach), the secret must be rotated and revoked immediately. All systems that used the secret must be updated to use the new value or must be taken offline until updated. The incident must be reported in line with the government’s incident response procedures. If the compromise involves personal data or affects systems under the Data Protection Act, breach notification to MACRA must be considered within the Act’s timeframe.

6.3 Break-Glass Access (Baseline)

Where break-glass credentials are required:

Break-glass secrets SHALL be stored in the secrets management solution with strict access control.

Access to break-glass secrets SHALL require MFA and SHALL be logged and reviewed.

Break-glass usage SHALL trigger an incident or post-event review, depending on severity.

6.2 Post-Incident Review

After a secrets-related incident, a post-incident review must identify root cause (e.g. secret in repo, weak access control) and corrective actions (e.g. scanning, training, policy change). Actions must be assigned and tracked to closure.

7. Verification and Evidence Baseline (Audit-Ready Secrets Management)

To make this standard auditable, ministries and secrets operators SHOULD maintain evidence that demonstrates: secrets in vault (inventory or coverage); no plain-text in repos (scan results); rotation compliance; access logs and retention; exception register. What internal audit checks: Sample of systems for vault use and repo scan; rotation and access logs; exception register. Sampling: Quarterly sample; annual review of exception register. Escalation: Non-compliance → System Owner and Security Officer → remediation plan; repeated → Document Owner and senior management.

7.1 Compliance Reporting

8. Legal Compliance and Governance

7.1 Data Protection Act (2024)

Where secrets protect or provide access to personal data, their compromise may constitute a security incident under the Act. Appropriate technical measures (centralised storage, access control, rotation, audit) support compliance. Breach notification to MACRA and to data subjects, where required, must follow the Act.

7.2 Electronic Transactions and Cybersecurity Act (2016)

The Act requires government to implement appropriate cybersecurity measures. Secrets management is a fundamental control; failure to protect credentials can lead to unauthorised access and legal or reputational harm. Audit trails support accountability and investigation.

7.3 Related Standards

This standard is used by the Malawi Government IAM Standards (credentials for authentication), the Malawi Government PKI and Certificate Management Standards (storage of private keys when not in HSM), the Malawi Government Infrastructure Automation and CI/CD Standards (pipeline and automation credentials), the Government Server Security Hardening Standards (no credentials in scripts or configs), and the Malawi Government Database Management Standards (database credentials).

9. Training and Awareness

8.1 Developers and System Administrators

Personnel who develop or operate systems that use secrets must be trained on this standard: no plain-text secrets in code or config, use of the central secrets solution, and how to integrate applications and automation with the solution. Training must include how to request access, how to rotate secrets, and how to report suspected compromise.

8.2 Security and Audit

Security Officers and auditors must understand how to verify compliance (e.g. scanning for secrets in repos, reviewing secrets solution logs and access policies) and how to interpret alerts and incidents.

10. Framework Alignment

This standard contributes to compliance with international frameworks. Refer to `ISO27001_Mapping.md` and `Multi_Framework_Mapping.md` for the complete mapping tables.

11. Appendices

Appendix A: Examples of Secrets (Non-Exhaustive)

Passwords (user, service account, database). API keys and OAuth client secrets. Private keys (when not in HSM). Connection strings containing credentials. Encryption keys (when not in HSM or KMS). Token signing keys. Certificate private keys (where not managed under PKI/HSM policy).

Appendix B: Related Standards

Malawi Government IAM Standards. Malawi Government PKI and Certificate Management Standards. Malawi Government Infrastructure Automation Standards. Malawi Government CI/CD Standards. Government Server Security Hardening Standards. Malawi Government Database Management Standards.

Appendix C: Control and Legal Mapping

• Appendix D: Evidence and Artifact Checklist
• Secrets solution: Evidence of designated solution; access control and IAM integration; encryption at rest and in transit.

No plain-text: Evidence of pre-commit or CI/CD secret scanning; no secrets in repos or config (scan results); remediation of historical repos.

• Rotation: Evidence of rotation schedule and logs; rotation on compromise or separation.
• Audit: Access logs (identity, timestamp, action) retained per policy; evidence of anomaly alerting.
• Exceptions: Exception register with requirement, justification, compensating controls, risk acceptance, and review/expiry dates.
• Appendix E: Templates (Minimum)

E.1 Secret Rotation Record (Template)

• Secret identifier/class and system owner
• Rotation reason (scheduled/compromise/separation)
• Date/time rotated and operator
• Systems updated and validation performed
• Evidence links (audit logs/change records)

E.2 Break-Glass Access Request/Use Record (Template)

• Requestor, approver, and authority basis
• Reason and scope
• Time window
• Actions performed and systems touched
• Post-event review outcome and corrective actions

References

Data Protection Act No. 3 of 2024 (Malawi).

Electronic Transactions and Cybersecurity Act (2016) (Malawi).

Malawi Government IAM Standards.

Malawi Government PKI and Certificate Management Standards.

Government Server Security Hardening Standards.

NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (IA-5, SC-12, AC-2).

NIST SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management (authenticator management).

CIS Benchmarks / DoD STIGs (credential and configuration security).