Lock Down Remote Work With IP Restrictions and Strong Authentication

It is 9:47 on a Monday morning. The accounting lead for a precision parts maker in Higashi-Osaka logs in from her kitchen to start the month-end close. She is one of about seventy staff, and the company runs double-entry books for roughly 480 million yen in annual sales. Two years ago she would have driven to the office and opened the ledger from a fixed PC on the company network. Today she works from a laptop on her home Wi-Fi.

That shift sounds convenient. For the CFO it sounds like risk. The ledger, the purchase orders, the qualified-invoice registration numbers, and the personnel data all sit behind one login screen. If a single credential leaks, the whole finance function opens to a stranger.

This is the real problem remote work created for Japanese small and mid-size companies. It is not productivity. It is not culture. It is that the front door to the core business system is now reachable from anywhere, and most companies have done very little to reinforce it.

The Quiet Security Gap in Most Japanese SMEs

Japan's Information-technology Promotion Agency (IPA) surveyed 4,191 small and mid-size enterprises in fiscal 2024. About 70 percent of them said they do not run information-security measures in any organized way, and roughly 60 percent had spent nothing on security over the previous three years. IPA published the results in May 2025.

Meanwhile the National Police Agency recorded 222 ransomware damage reports in 2024. Around 60 percent of those reports involved SMEs, and ransomware has held the number-one spot in IPA's top-threats list for over a decade.

The honest reading is that most Japanese companies know the threat is real and have still not changed how their staff log in. A password. Maybe a shared one. Saved in the browser. Reaching the core business system from a phone on a train.

That posture was survivable when the system lived on a server in a back room behind the office router. It is not survivable when the same system is cloud-hosted and the office router is no longer in the path.

The Layered Model: What Strong Access Actually Means

Security people talk about defense in depth. For a finance and operations leader, the practical version comes down to four layers, each of which can stop an attack on its own.

Where you can log in from. Restrict the system to known networks and known locations. The office. The branch in Nagoya. The home IP of the two people who close the books. Everything else is refused before the login screen even matters.

Who you are. A password, stored properly and never reused, with history checks that stop people cycling back to old passwords.

Something only you hold. A six-digit code from an authenticator app that changes every thirty seconds, or a passkey bound to a device. Even if the password is stolen, the attacker still cannot get in.

What you can do once inside. Access granted by role, so the warehouse team sees inventory and the accounting team sees the ledger, and neither can wander into the other's records.

A core business system that implements these four layers together is a different animal from one that relies on a password alone. Let's look at what each one looks like in practice.

Restricting Logins to Trusted Networks

The most underused control in Japanese SMEs is the IP allowlist. The idea is simple and powerful: the core business system only accepts connections from addresses you have approved. A login attempt from an unknown cafe in a foreign country never reaches the credential check. It is refused at the door.

A capable system supports three ways to express the rule. A single IP address for one fixed location. A CIDR range, such as 10.0.0.0/24, for an entire office subnet. And an inclusive range, such as 192.168.1.1 through 192.168.1.100, for a block of addresses a home worker might rotate through.

The system should let you choose between two enforcement modes. An allowlist admits only the addresses on your approved list and blocks everything else. A denylist does the inverse. For finance data the allowlist is almost always the right choice, because you want to name what is permitted rather than chase what is not.

A small but important design detail: the system should fail open when no rules are defined yet, so you cannot accidentally lock your entire company out on the day you turn the feature on. Once you add the first trusted range, enforcement begins.

There is also the matter of how the system reads the real client address when traffic passes through a proxy. A well-built restriction layer reads the standard forwarded headers and the cloud-provider headers, so the address it evaluates is the actual user, not the proxy in front of it.

This single control closes a surprising amount of risk. Phished credentials become useless if the attacker sits on a residential line in another prefecture. The login simply does not resolve.

TOTP Two-Factor: The Code That Expires

Even inside an allowed network, a shared or stolen password is still a problem. This is where two-factor authentication comes in, and it is a real, built capability, not a roadmap promise.

The mechanism is TOTP, the time-based one-time password standard. A user pairs the core business system with any authenticator app by scanning a QR code or entering a manual key. From then on, every login asks for a fresh six-digit code that changes every thirty seconds. The code is generated locally on the phone and never sent to the server.

Good implementations add two things that matter for operations. First, backup codes. When a user enables two-factor, the system generates a set of single-use recovery codes. If a phone is lost or replaced, a backup code gets the user back in long enough to re-pair a new device. Second, a sensible verification window that accepts the code from the adjacent time step, so a user with a clock a few seconds off is not rejected.

Disabling two-factor should require the account password. This is a small but meaningful guardrail. It stops an attacker who briefly borrows an unlocked session from quietly removing the second factor.

For a finance team, the practical effect is that a leaked password on its own no longer opens the ledger. The attacker would also need the user's phone, in the same thirty-second window. That is a steep increase in cost for the attacker and a steep drop in risk for the CFO.

TOTP is strong, but it still starts with a password, and passwords remain the thing people reuse and leak. Passkeys remove the password from the login entirely.

A passkey is a credential bound to a device using an industry standard for passwordless login. During registration, the user's device creates a public-private key pair. The private key never leaves the device. The server stores only the public half. At login, the server sends a challenge, the device signs it locally, and the signed response proves the user has the device without the password ever being typed or transmitted.

A complete passkey implementation lets users register multiple devices, give each one a friendly name, rename them, and delete a lost one without losing access to the others. It supports both a username-first flow and a discoverable flow where the device itself offers the right credential.

There is one operational detail worth knowing. A mature system treats passkey login and two-factor login as connected. If an account has two-factor enabled, even a successful passkey sign-in still challenges for the second factor. That way the strongest path to entry is also subject to the second layer, and an admin can roll out passkeys without weakening policy for accounts that already use TOTP.

For the accounting lead, a passkey means she logs in with her laptop's fingerprint reader. No password to phish. No code to mistype. Faster for her, safer for the company.

Passwords Done Properly, for the Accounts That Still Use Them

Not every account will move to passkey on day one, and partners in the B2B portal may always use passwords. So the password layer still has to be sound.

That means hashing with a strong, slow algorithm at a reasonable cost factor. It means password history checks, following the NIST 800-63B guidance, so a user cannot cycle back to one of their last several passwords. It means a minimum age before a password can be changed again, which blocks the trick of cycling through five throwaway passwords to get back to a favorite. And it means secure reset flows with short-lived tokens and rate limits, so the reset path itself is not the weak link.

Boring details, but they are exactly the details an auditor or a security-conscious customer will ask about during vendor review.

Access by Role, and Data That Stays Separate

Authentication is who gets in. Authorization is what they can touch once they are in. A core business system has to answer both.

Access is granted by role. An admin defines roles and assigns them to people, and the system shows each person only the functions and records their role permits. The warehouse lead sees movements, transfers, and shipments. The accounting lead sees invoices, bills, journal entries, and budgets. The sales lead sees quotations and sales orders. Nobody gets the full surface by default.

Then there is the question of company boundaries. A holding company running several entities, or a services firm managing separate books for separate clients, needs each company's data to stay fully isolated. The right architecture isolates data at the company level so a user in one entity never crosses into another's ledger, even by mistake, even through a shared feature.

This matters more than it sounds. When the audit team asks who could have seen the figures for entity B, the answer should be a short, certain list.

How It Looks in a Real Week

Return to the precision parts maker. The CFO turns on the IP allowlist on a Tuesday. He adds the office CIDR in Higashi-Osaka, the Nagoya sales branch, and the home addresses of the five people who touch the ledger. He requires TOTP two-factor for every account with finance access, and he migrates himself and the accounting lead to passkeys.

What changes is quiet but large.

The monthly close, which used to run from a fixed machine in the office, now runs from anywhere the accounting lead happens to be, with no loss of control. A vendor whose login details leak in some unrelated breach still cannot reach the ledger, because the credentials are useless without both the TOTP code and a network on the allowlist. When a staff member leaves, the admin removes the role and the passkey, and the door closes cleanly.

None of this required a custom build or a six-month security project. It required a core business system that shipped these controls as standard features and an admin willing to switch them on.

Frequently Asked Questions

Will IP restrictions lock out our staff when they travel?

They can, if you set them too tight. The practical pattern is an allowlist of fixed locations plus a documented process to add a temporary range for a known business trip. The trade is deliberate friction for a known risk, and most finance teams prefer a short approval step over an open login from anywhere.

Is two-factor a burden at month-end when people are stressed?

The code entry adds a few seconds per login, and passkeys remove even that. The realistic cost is one support conversation when someone replaces their phone, which is exactly what backup codes are for. Against a leaked credential, that small cost is cheap insurance.

We are a small company. Is anyone really targeting us?

Attackers go where defenses are weakest, not where the headlines are, and survey data shows the majority of reported ransomware damage involves small and mid-size companies. An unconfigured cloud login is a soft target regardless of company size. Kikan System ships these controls as standard features so a smaller team gets the same hardened front door as a large group.

Can we keep using our existing passwords during the transition?

Yes. A well-designed system lets you phase the rollout. Start with IP restrictions, then require two-factor for finance roles first, then move power users to passkeys. You do not have to flip the whole company on one afternoon, and you can stage the rollout on the free plan for up to 2 users, no credit card required.

What happens if a passkey device is lost?

A complete passkey implementation lets users register multiple devices, name them, and delete a lost one without losing access to the others. Backup codes generated when two-factor is enabled also provide a recovery path back in, long enough to re-pair a new device.

Key Takeaway: Remote work is not going to reverse, and the front door to your finance data is not going back inside the office router. The fix is not more willpower about passwords. It is a core business system that enforces trusted networks, time-based second factors, passkeys, and access by role as standard controls you simply switch on.

Why This Belongs in the Platform, Not Bolted On

You can buy authentication tools individually. A standalone two-factor service. A separate network filter. Many Japanese companies do, and end up with multiple vendors, multiple bills, and several places where policy can drift out of sync.

The argument for putting these controls inside the core business system is consistency. The same system that knows which invoices exist, which roles exist, and which company boundary applies is the system that enforces who can see them. When a person leaves, removing their access updates one source of truth. When an auditor asks for evidence, the access story matches the data story.

This is what Kikan System is built to provide. Trusted-network restrictions, TOTP two-factor authentication, passkey login, password history, access granted by role, and per-company data isolation live together inside the same platform that runs your accounting, inventory, manufacturing orders, and approvals. You configure them from the admin screen, and they protect every module underneath.

If your team is working remotely and your current setup is still just a password, start there. The free plan covers up to 2 users with no credit card, which is enough to evaluate the access controls against your real workflow. See get started to try it, or review the plans at pricing.

Strong access is not a feature you add later. It is the floor your core business system stands on.