Hardware over habit
If a private key can be copied, eventually it will be. We design so it cannot be.
- Keys generated inside the HSM, never imported
- Physical tokens for operator identity
- No shared administrator credentials
About
A small team with an unfashionable specialism.
SK Enterprise builds the parts of a system nobody demos: the certificate that proves an identity, the hardware that guards a key, the channel a file travels down. Then we build the product on top.
Our story
We got tired of watching good systems fail at the seams.
SK Enterprise started the way most useful companies do — with a problem that kept recurring. Working on integration projects, we kept meeting the same weak joints: a certificate authority stood up years ago and never documented, a private key sitting in a configuration file, an FTP drop guarded by a password four organisations knew, a scheduled script that silently stopped running in March.
None of these were exotic failures. They were the boring, structural kind — the sort that never make it onto a roadmap because no single team owns them. So we built the tools we wanted to have on those projects, and the practice around them: the Root CA System, then SftpS, and the design, hosting and development work that surrounds any real deployment.
We are a young company and we say so plainly. What we bring is not a long client list — it is depth in a narrow, unglamorous field, and a habit of writing down what we did so you are never dependent on us to understand your own system.
2
products built in-house and deployed on customer hardware
10
service disciplines practised by the same accountable team
0
private keys that ever touch a disk in our designs
How we think
Six commitments we will not trade away.
These are not values on a wall. Each one costs us something, which is how you know we mean it.
Standards over lock-in
Published protocols mean your next vendor can take over without a rewrite.
- PKCS#11, ACME, SCEP, OCSP, RFC 3161, SFTP
- Documented data formats and export paths
- No proprietary client software required
Write it down
An undocumented system is a system with one point of failure, and it is a person.
- Architecture, policy and ceremony records
- Runbooks your team can execute alone
- Handover training as part of delivery
Say the uncomfortable thing
If the cheaper option is the right one, or the project should not happen, we say so early.
- Honest scoping before a contract exists
- Risks named in writing, not in a hallway
- We decline work we cannot do well
Stay after go-live
Certificates expire, dependencies rot, and staff move on. Somebody has to be watching.
- Monitoring and expiry alerts from day one
- Patching on a published cadence
- A named engineer who knows your estate
Build for the operator
The person on shift at 3am is the real user of a security system.
- Clear errors that name the cause
- Dangerous actions require deliberate confirmation
- Recovery paths tested, not theorised
Capabilities
What we actually work with.
No stack is a personality. This is simply what we have shipped with, and what we are prepared to be accountable for at three in the morning.
Identity & PKI
- Keycloak
- OpenID Connect and OAuth 2.1
- SAML 2.0
- X.509 and RFC 5280
- YubiHSM 2 and PKCS#11
- YubiKey PIV and FIDO2
- OCSP and CRL
- RFC 3161 timestamping
- PAdES and CAdES signatures
- ACME, SCEP and EST
Secure transport
- SFTP over SSH-2
- FTPS over TLS 1.3
- SSH certificate authorities
- Mutual TLS
- OpenSSH and libssh
- Certificate pinning
Platform & runtime
- Linux (Debian and RHEL family)
- Docker and Kubernetes
- NGINX and HAProxy
- PostgreSQL and MariaDB
- Prometheus and Grafana
- Infrastructure as code
Application
- Java and Spring Boot
- Kotlin and Ktor
- Vaadin
- Thymeleaf server rendering
- Jetpack Compose
- Kotlin Multiplatform
- Compose Multiplatform
- Swift for iOS
- n8n workflow automation
Working with us
What the first month looks like.
You should be able to judge us on evidence well before the invoice that matters.
01
Week one — listen
A working session with your engineers and the people who carry the risk. We leave with a written statement of the problem, agreed by both sides.
02
Week two — design
An architecture, a threat model and a risk register. Where an off-the-shelf product would serve you better than us, that is in the document too.
03
Week three — prove it
A working slice in a pilot environment: a real certificate issued, a real file transferred, a real notification delivered.
04
Week four — decide
Fixed scope, fixed price and a delivery plan. If the pilot changed our mind about the approach, we say that instead.
We would rather be useful than impressive.
Bring us the part of your system you have been avoiding. That is usually where we do our best work.