Single Sign-On and Enterprise Security for Virginia Organisations

Name: Vikk Ai
Telephone: +1
Price range: $$

Single sign-on is the one enterprise feature that reduces work rather than adding it, because it extends controls you already built instead of creating a second set to maintain. What that is worth in Virginia depends on what drives your requirements in the first place.

What Actually Drives Requirements in Virginia

Federal contracting drives the strictest requirements in the country outside the federal government itself, with flow-downs that exceed most regulation. Data centre and technology operations add customer-driven review, and healthcare systems add privacy obligations.

The matters flowing through these deployments concentrate in employment and workplace questions and landlord and tenant matters, the two areas generating the highest volume from this state.

Which SSO Benefit Returns the Most Here

For federal contractors, inheriting an identity control set already accepted by a federal customer is frequently the only viable path, since a parallel set would need to pass the same review.

The Retention Decision You Face

Federal contract terms dictate retention independently of state obligations and can require considerably longer periods. Contract terms first, always.

What the Security Review Looks Like

The most demanding reviews in the country outside federal agencies themselves. Establish what the review will permit before scoping, because it determines the boundaries rather than the feature list.

What to Actually Ask For

Ask what a federal customer has accepted and what a security review has permitted, and ask whether your contract terms permit the data paths involved. Both can prohibit what the product supports.

What Single Sign-On Actually Gives You

One identity, inherited controls
Users sign in with corporate credentials; password policy, MFA enforcement and conditional access come from your identity provider. No second control set to maintain or let drift, which is the actual benefit rather than convenience.
Provisioning that keeps up
Users added to the right identity provider group get the appropriate role and workspace access automatically. No manual creation, and no gap between starting and having access.
Deprovisioning that does not depend on memory
Removal from the identity provider removes access. Accounts outliving employment is the most common real exposure in any organisation with turnover, and this closes it without anyone having to remember.
Group-based access that matches your structure
Identity provider groups map to workspaces and roles, so access follows the org chart rather than a separate list somebody maintains.
MFA where you already manage it
Enforceable for all users, admins or specific groups, at login regardless of access method. With SSO it is typically enforced at the identity provider, which is where you want it.

Audit, Retention, and Controls

Audit logging of significant events Provisioning, login events, policy changes, deletions, admin actions and API calls, with timestamp, actor, action, target and outcome. Exportable, with SIEM integration at higher tiers.

Retention configurable per workspace Different workspaces can carry different windows, which matters because different record types carry different obligations. Available windows and current defaults are on the main security page rather than repeated here.

Residency, keys, and healthcare agreements Data residency where available, customer-managed encryption keys for deployments with specific regulatory drivers, and business associate agreements at the appropriate tier for organisations handling protected health information.

Why One Retention Policy Cannot Cover Fifty States

The product documentation offers an example of a workspace retaining records for a set number of years for employment law reasons. The number is not reproduced here, and the reason is worth stating: record retention obligations differ by state and by record type, and a single policy cannot satisfy all of them.

Too short destroys records you were required to keep: An automatic deletion policy applied to records with a longer obligation deletes them on schedule and without warning. That is the failure mode nobody notices until it matters.
Too long keeps records that become discoverable: Retained records are available to a party who is entitled to request them. Retention beyond what you need is a liability rather than a neutral default.
Record types and contract terms both cut across it: Employment, clinical, regulated-process, financial services and grant-funded records are not one category, which is why per-workspace policy exists. Federal contracts, customer agreements and funder terms also dictate retention independently of any state requirement, and are frequently longer. Establish those first.
Whoever picks the number should not be guessing: This is a question for counsel, not for a default setting. The right answer is a small number of per-workspace policies set with advice, not one number chosen because it sounded conservative.

What the Audit Log Records About You

One thing about single sign-on belongs in front of employees as well as administrators. Audit logs capture login events, with timestamp and actor, and that is by design and appropriate. It also means the record of who used the system, when, and from where exists independently of whether anyone can read the conversations.

Content privacy and access privacy are different. Conversation content can be private to you while the fact and timing of your login is visible to your employer's security function. That distinction catches people out because the first reassurance sounds like it covers both.
The timing itself can be informative. A login the evening before a resignation, or the day a disciplinary meeting was scheduled, is a data point regardless of what was discussed. Nothing needs to be read for that to be true.
For a matter concerning your employer, use a personal account. On a device your employer does not manage, with an email address they do not administer. That removes the trail rather than protecting the content within it.
Administrators should say this plainly. Employees using an SSO-provisioned account should be told what the audit log records. An organisation that logs login events without saying so has created an expectation problem for itself as well as for its people.

In cleared environments, login events on employer or agency systems carry consequences that can reach a clearance rather than only a matter. Personal device and personal account, without exception.

Virginia Frequently Asked Questions

Our contract sets our security requirements. Where do we start?

With the contract terms and the security review outcome, before evaluating features. In this market both can prohibit configurations the product supports.

Can we use our own identity provider?

SAML 2.0 and SCIM are supported with major providers and custom providers at the appropriate tier. If you already run an identity provider, that is the integration worth doing first because it reduces administration rather than adding to it.

Which MFA methods are supported?

Authenticator apps and hardware security keys, with backup codes for recovery. SMS is supported and not recommended, because SIM-swap attacks make it the weakest of the options. Where SSO is configured, MFA is usually enforced at your identity provider instead.

What should we ask for during a security review?

Security documentation, current attestation status stated precisely rather than in summary, and an architecture briefing if your process includes one. Asking for the current status in writing is reasonable and worth doing rather than relying on a marketing page.