Security practices for visitor access operations.

• Protect visitor, resident, staff, organization, and operational security records from unauthorized access.
• Keep each customer organization separated from other customer organizations.
• Reduce the risk of account takeover, accidental exposure, duplicate actions, and stale gate records.
• Preserve audit evidence for key security, onboarding, export, visit, and administrative actions.
• Support fast, simple operations for gate teams without sacrificing privacy controls.

Role-based access

Access is separated by roles such as platform owner, organization admin, security officer, host or resident, and manager viewer.

Tenant scoping

Operational records include organization boundaries so users only interact with records that belong to their organization and role.

Password and token handling

Passwords are hashed. Invite and password reset tokens are stored as hashes, expire, and are designed for one-time use.

Secure sessions

Authenticated sessions use signed HTTP-only cookies and server-side role checks for protected pages, API routes, and server actions.

Rate limiting

Sensitive flows such as login, password reset, invites, fresh invite emails, exports, and test notifications use rate limits to reduce abuse.

Audit trails

Important actions can be recorded with actor, organization, entity, timestamp, user agent, and limited metadata for accountability.

• Production access is served over HTTPS through managed hosting infrastructure.
• Baseline security headers are configured, including content type protection, framing restrictions, referrer policy, and permissions policy.
• Production secrets are stored in deployment environment variables and must not be committed to source control.
• Database access uses managed PostgreSQL connection settings configured in production environment variables.
• Transactional email is sent through an authenticated email delivery provider using a verified domain.

• Gate screens can route visitors through destination codes and aliases instead of exposing private resident or staff names.
• Organization administrators control users, roles, gates, and destination links.
• Host and resident views focus on their own approval workflow instead of broad visitor surveillance.
• Platform owner views are designed to favor operational readiness and aggregate risk signals over private visitor-level browsing.
• CSV exports and audit access are role-scoped and rate-limited.

• Browser and installed-app push notifications require user permission and an active device subscription.
• Service worker behavior is restricted so authenticated dashboard navigation is not served from unsafe stale cache.
• Users can disable push notifications on a device when they no longer want that device to receive alerts.
• Notification delivery depends on browser, device, operating system, and network support.

If we identify a security incident, we will work to contain the issue, investigate scope, preserve relevant evidence, mitigate impact, and notify affected customers or authorities where required by applicable law or contract.

If you believe you found a security weakness in AccessLynk, please report it promptly and avoid accessing, modifying, deleting, or sharing data that does not belong to you. Contact lnykbridgetechnologies@gmail.com.