Security hardening & SSL
before the bad week.
Hardening, patching, certificates and headers — the unglamorous work that prevents the bad week.
- — You have been compromised before, or nearly were
- — API keys live in the codebase or a shared document
- — Former staff may still have production access
The work should
change the numbers.
Most sites are not compromised by anything sophisticated. They are compromised by an unpatched plugin, a reused admin password, a form without rate limiting, or an API key committed to a repository three years ago and never rotated.
This is unglamorous, high-leverage work. We close the common paths first, then reduce what an intruder could reach if they got in at all: least-privilege access, secrets rotated, backups verified, logs retained somewhere an attacker cannot edit them.
You get a written posture assessment with severities, the fixes applied, and a runbook so an incident is a procedure rather than a panic.
What the engagement
actually contains.
Security posture assessment
Exposed surfaces, dependency vulnerabilities, access review and configuration weaknesses documented with severities.
Patching and dependency policy
Automated scanning with a defined cadence, plus a path for urgent out-of-band patches.
TLS and security headers
Modern TLS, HSTS, CSP, frame and referrer policies configured and tested rather than copied from a blog post.
Authentication hardening
MFA, session policy, brute-force and rate limiting, and password rules that follow current guidance.
Secrets and access control
Keys moved into a manager, rotated, and access reduced to least privilege with joiners-and-leavers process.
Backup, logging and incident runbook
Verified restores, tamper-resistant logging, and a rehearsed response plan with named owners.
- Security assessment with prioritised severities
- Applied hardening changes with evidence
- Security header and TLS configuration report
- Secrets inventory with rotation record
- Verified backup and restore evidence
- Incident response runbook
- You have been compromised before, or nearly were
- API keys live in the codebase or a shared document
- Former staff may still have production access
- A client security questionnaire arrived and you cannot answer it
What usually went wrong
before we were called.
- 01Secrets committed to a repository and never rotated
- 02Leavers keeping production access because there is no offboarding step
- 03Security headers copied from a blog post and never tested
- 04Restoring from backup without finding the root cause, then being hit again
- Open critical vulnerabilities
- Patch latency after disclosure
- Accounts with production access
- Time to contain a simulated incident
2–4 weeks for assessment and hardening
What week one
actually looks like.
Exposed surfaces, dependency vulnerabilities and access lists reviewed, with findings ranked by consequence. Anything critical is contained in week one rather than scheduled.
- Repository, hosting and DNS access
- A current list of who has production access
- Secrets inventory, however incomplete
- An incident escalation contact
- Penetration testing or red teaming
- Compliance certification (SOC 2, ISO 27001)
- Corporate endpoint security
- Legal or breach notification advice
Scope boundaries stated up front rather than discovered in a change request.
Four stages, visible throughout.
Assess
A baseline across performance, security, accessibility and dependency risk, with findings ranked by consequence.
Stabilise
The urgent items closed first: exposed surfaces, failing checks, missing backups, unpatched dependencies.
Automate
Budgets, scans and alerts moved into CI and monitoring, so regressions are caught by machines rather than customers.
Review
A quarterly session on what changed, what is drifting and what deserves next quarter’s attention.
Security hardening & SSL, answered.
No. This is hardening: closing the well-known paths and reducing blast radius. It is what should happen before a penetration test, so the test finds interesting things rather than the obvious ones. We can coordinate a third-party test afterwards.
Yes. Containment first — isolate, preserve evidence, rotate credentials — then clean-up, restoration from a verified backup and root-cause analysis. Skipping the root cause is why sites get compromised twice.
It encrypts traffic in transit, which is necessary and nowhere near sufficient. The real risks are usually in authentication, unpatched dependencies and over-broad access. Certificates should be automated and then largely forgotten about.
Website & app maintenance
Ongoing updates, monitoring and a senior person to reach when something needs deciding.
Hosting & domain management
Infrastructure, DNS and deploy pipelines managed so uptime stops being your problem.
Payment gateway integration
Stripe, PayPal, Adyen and regional gateways wired in with tax, refunds and edge cases handled.
QA & testing
Manual and automated coverage that finds the failure before your customers volunteer to.
Make security hardening & ssl useful.
Bring us the hard thing. We will bring a point of view, a senior team and a clear next step.