Access and Security
Access control your auditor can follow.
Identity is who you are. Authorization is what you may do. Attention tends to go to the first question, and the second is where systems quietly get it wrong.
We build both halves: single sign-on and multi-factor authentication at the front door, and authorization checks that run on the server, on every request. Then we write it down, so the answer to "who can touch this" is a lookup, not a meeting.
Where breaches actually happen
The login is not the weak point. The check after it is.
An attacker rarely picks the lock. The usual entry is a real credential: a phished password, a stolen session token, a service account nobody rotated. Once inside, the only thing between that credential and your data is authorization, the logic that decides what each identity may read, change, or delete.
That logic must run on the server, on every request. A permission check that only exists in the user interface is decoration. Hiding the Delete button does not remove the endpoint behind it, and anyone who opens the browser's developer tools can see exactly what you hid. The interface can hide what a user should not do. Only the server can refuse it.
Our working rule: every endpoint decides for itself, from the identity on the request, whether the caller may do what it is asking. The client's opinion is never consulted.
One login
Single sign-on
Single sign-on means your staff authenticate once, against the directory your company already manages, and every internal application trusts that sign-in. No separate password per app. No spreadsheet of credentials. When an employee leaves, you disable one account and every door closes at once.
Without it, the account list is the exposure list. Every application with its own password table is one more place offboarding can miss, one more database that can leak, one more password your users will reuse.
We wire applications to the identity provider you already run, Microsoft Entra ID or Google Workspace among them, using OpenID Connect for modern applications and SAML where an older system demands it. We also retrofit single sign-on onto line-of-business applications that were built with their own login screens. The retrofit is most of the real work, and it is work we do in .NET, where the supporting libraries are mature.
The second factor
Two-factor and multi-factor authentication
Passwords leak. They get phished, reused across sites, and sold in bulk when some other company is breached. Two-factor authentication adds a second, independent proof: something the user holds, not something they typed. An authenticator app, a hardware key, a passkey. With that second factor in the path, a stolen password is no longer enough to become you.
Codes sent by text message can be intercepted, or talked out of a phone carrier by a patient stranger. We prefer phishing-resistant factors: passkeys and hardware keys first, authenticator apps second, SMS only when nothing else is workable.
The part that decides whether a rollout holds is not the factor. It is enrollment and recovery. If a caller can reset multi-factor authentication with a birthdate and a friendly voice, the second factor exists in name only. We design the recovery flow with the same seriousness as the login itself, because that is where the pressure goes next.
Machine to machine
Two-way TLS between machines
Ordinary TLS authenticates one direction. Your browser verifies the server's certificate; the server learns nothing about who is calling. Mutual TLS, also called two-way TLS, completes the handshake in both directions: each side presents a certificate, and each side verifies the other's. The server knows which machine is calling, not just that someone is.
That matters wherever software talks to software with no human present to type a password: a partner posting orders to your API, services inside your own network calling one another, a background job pulling from a warehouse system. An API key in a config file is a password that never changes and copies freely. A client certificate is an identity that can be issued, scoped, and revoked.
The hard part of mutual TLS is not the handshake. It is the certificate lifecycle. A certificate that never expires is a credential that never rotates, and one that expires with nobody watching is an outage on a schedule. We plan issuance, rotation, and revocation before the first certificate is cut, and we monitor expiry so renewal is routine instead of an emergency.
How the work runs
Practice, written down.
This page describes practice, not a warranty. Nobody can promise you will not be breached, and you should be wary of anyone who does. What we offer is work you can inspect: every decision recorded in Azure DevOps, every control exercised by a test. The work runs in this order.
- Inventory. Every application, every service account, every shared password, every place a person or a machine can authenticate today.
- The front door. Single sign-on against your identity provider, with multi-factor authentication enforced and phishing-resistant factors preferred.
- Server-side authorization. Roles and permissions defined in one place and enforced at every endpoint, with the deny rules as explicit as the allows.
- Machine identity. Mutual TLS between services where no human is in the loop, with certificate rotation planned before the first certificate is issued.
- Proof by test. Automated tests that assert the refusals: the wrong role gets denied, the missing certificate gets rejected, the expired session cannot act. A control that is never exercised is a control on paper.
Start here
Tell us where access is fuzzy.
Describe the system, who signs into it today, and the part that worries you. We will tell you honestly whether it is a small wiring job or a real project.
Monday to Friday, 8:00am to 5:00pm Eastern. Based in the Tampa Bay area, Florida, serving clients nationwide.