A ten person fintech can separate duties without hiring a security team. Make sure the person who writes a payment change is not the sole person who approves it, deploys it, or holds the production keys. Enforce multifactor authentication, least privilege and logging across source control, CI and cloud.
Why small teams need it
The OWASP Software Supply Chain cheat sheet calls compromised accounts, particularly privileged ones, a significant threat. Account takeover can let an attacker inject code into legitimate dependencies, manipulate CI/CD pipeline execution, or swap a benign artifact for a malicious one. Its recommended basics include least privilege, separation of duties, enforcing MFA, rotating credentials and never storing credentials in clear text or in source control.
In a tiny team, everyone has every permission because it is convenient. That convenience is exactly what an attacker, or one honest mistake, can exploit.
Four roles to keep apart
| Duty | Who typically does it | Control that separates it |
|---|---|---|
| Write the change | Any engineer | Pull requests required, no direct pushes |
| Approve the change | A different engineer, a code owner for payment paths | Required approvals and code owner review |
| Deploy the change | A pipeline, approved by someone other than the author | Environment reviewers with self-review blocked |
| Hold production secrets | The runtime and a very small group | Secrets manager with fine-grained access |
You will not always have enough people for four separate individuals. The goal is that no single person, and no single compromised account, can complete the whole path from writing to production alone.
Practical settings
- Enforce MFA on source control, CI, cloud consoles and the secrets system.
- Make production access a role that people request and lose, rather than a standing default. Time boxed access is easier to defend.
- Require pull request approvals with code owner review on payment paths, as covered in our post on two person review.
- Use a production environment that needs approval from someone other than the author.
- Give CI designated service accounts scoped to the secrets they need. OWASP's secrets guidance says each pipeline run should be attributable to the person who defined or triggered it.
- Limit who can edit workflow files, since those files control what runs.
Logging that supports the split
OWASP's supply chain guidance says all systems in the supply chain, including source control, build tools, delivery mechanisms, artifact repositories and runtime systems, should log authentication attempts, configuration changes and other events useful for spotting anomalous behavior. It adds that logging is not enough: logs must be monitored and acted upon, ideally in a central place.
For a small team, that can mean a short list of alerts: a new admin added to the repository, a change to a branch rule, a new deploy key, a production secret read outside normal hours.
Handling the awkward cases
- The founder with admin everywhere. Use a separate admin account for administration and a normal one for daily work. Review that the admin account has MFA and a recovery plan.
- On call emergencies. Define a break-glass path with named people and a record. Do not leave an unrecorded shared administrator login.
- Contractors. Give the lowest role that works on the specific repository, with an end date.
- Automation accounts. Give each a name, an owner and a purpose.
Review quarterly
Access drifts. Once a quarter, list who can approve, deploy and read production secrets, and remove anyone who no longer needs it. Write down the date and the changes. That record is useful if a partner or customer asks how access is controlled.
Be honest about the limits
Separation of duties reduces single points of failure. It does not stop collusion, and it depends on the underlying tools being configured as you believe. Test it: ask an engineer without special rights to try to deploy to production directly and confirm it fails.
Where Safeguard fits
Safeguard's agent identity feature helps you track automated actors, and its policies and gates enforce checks at the pull request. A free scan is available at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through and note who or what must approve before a change can move forward.
Quick check
Can one person be both approver and deployer?
It is better to avoid it for payment code. If the team is too small, add a compensating control such as a recorded second review after the fact.
What is the quickest first step?
Turn on MFA everywhere and require pull request approval on your payment repository.
Sources
Last reviewed: 19 October 2026.
