Access is two different decisions.
Decide which inbound path may reach the selected FocalShift Ai Hardware server. Then require a second proof before a password becomes a completed FocalShift Ai account sign-in.
One asks what may reach the server. One asks who may finish signing in.
A narrow network path does not verify a person. A valid authenticator code does not decide which server port is reachable. Keep each control accountable to its own boundary.
Does this source, using this protocol, have permission to reach this port?
The firewall lists configured inbound paths. A matching rule represents that network path as allowed; no matching inbound rule means this firewall blocks it.
An allowed path does not prove the service behind it is patched, authenticated or safe.
No firewall, no inbound rules, and one allowed path are not the same state.
FocalShift Ai reports only the firewall state it can confirm for the selected member-owned Hardware server. Unknown never becomes protected. Empty never becomes off.
Not filtered by this firewall layer.
No associated firewall was found for the selected server. Adding the first valid inbound rule creates that protection.
Say the path before you open it.
This is a local educational example. It accepts no real address or port, reads no authenticated server, and changes no rule.
The visible custom-rule surface currently exposes TCP and UDP. HTTP, HTTPS and SSH shortcuts are conveniences—not recommendations to expose every service to every source.
Anywhere widens the path. Removing a rule closes it.
An Anywhere source lets the public internet attempt the selected port. Removing a rule blocks traffic that depended on that exact protocol, port and source.
Broader reach is not automatically wrong. It must be intentional, necessary and reviewed.
The configured path reaches the illustrative service. No live service check is implied.
A correct password still stops at the second line.
FocalShift Ai uses authenticator-app two-factor authentication. When enabled, password success creates a pending second-factor step—not a completed member session.
Begin from your own account.
Enrollment starts inside the signed-in member’s Security Center and remains scoped to that member.
The setup QR and manual key belong in the authenticated Security Center. This page renders no usable QR, secret, authenticator code or password. Current TOTP is a useful second factor; it is not marketed as phishing-resistant.
Ten fallbacks. Each one disappears after use.
Successful enrollment currently creates ten one-time recovery codes. Plain values are shown once, stored verifiers are hashed, and an accepted code cannot be replayed.
Store them somewhere protected and separate from the authenticator. This page invents no help-desk, SMS or email-code bypass.
10 illustrative codes remain.
Turning 2FA off asks for the password again.
FocalShift Ai requires password reverification before removing the enrolled factor. A session alone is not presented as enough.
Current configuration can require administrator roles to enroll. That option is not generalized to every member or every workspace.
Two-factor authentication remains part of future sign-ins.
Protection gets clearer when every layer keeps its own promise.
Firewall and 2FA are part of a connected FocalShift Ai operating practice. None of these pages proves that another layer is configured.
Let the needed route through. Make the account ask twice.
Open only the inbound path the service needs, then use authenticator-app 2FA to keep a password from becoming the final word.